lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4780FD48.4030505@student.ltu.se>
Date:	Sun, 06 Jan 2008 17:09:44 +0100
From:	Richard Knutsson <ricknu-0@...dent.ltu.se>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	heiko.carstens@...ibm.com, olof@...om.net, mingo@...e.hu,
	mpm@...enic.com
Subject: Re: [patch 1/5] Introduce __WARN()

Arjan van de Ven wrote:
> On Sun, 06 Jan 2008 12:44:56 +0100
> Richard Knutsson <ricknu-0@...dent.ltu.se> wrote:
>
>   
>> Arjan van de Ven wrote:
>>     
>>> From: Olof Johansson <olof@...om.net>
>>>
>>> Introduce __WARN() in the generic case, so the generic WARN_ON()
>>> can use arch-specific code for when the condition is true.
>>>
>>> Signed-off-by: Olof Johansson <olof@...om.net>
>>> Cc: <linux-arch@...r.kernel.org>
>>> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>>> ---
>>>
>>>  include/asm-generic/bug.h |   17 +++++++++++------
>>>  1 file changed, 11 insertions(+), 6 deletions(-)
>>>
>>> Index: linux-2.6.24-rc6/include/asm-generic/bug.h
>>> ===================================================================
>>> --- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
>>> +++ linux-2.6.24-rc6/include/asm-generic/bug.h
>>> @@ -31,14 +31,19 @@ struct bug_entry {
>>>  #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); }
>>> while(0) #endif
>>>  
>>> -#ifndef HAVE_ARCH_WARN_ON
>>> +#ifndef __WARN
>>> +#define __WARN() do
>>> {							\
>>> +	printk("WARNING: at %s:%d %s()\n",
>>> __FILE__,			\
>>> +		__LINE__,
>>> __FUNCTION__);				\
>>> +
>>> dump_stack();
>>> \ +} while (0) +#endif
>>> +
>>> +#ifndef WARN_ON
>>>  #define WARN_ON(condition)
>>> ({						\ int
>>> __ret_warn_on = !!(condition);				\ 
>>>       
>
>   
>> What about using a boolean for __ret_warn_on, which then let us
>> remove the '!!'?
>>     
>
> is iffy.. like what happens if an u64 is cast to a boolean?
> No matter what the final assembly code will need to be the same
>   
Well, the main point were to use the boolean type instead of an integer...
What about u64? "true" is still "not zero", and is really the assembly 
the same for !!u8, !!u64 and !!pointer? Isn't that the reason to use a 
macro instead of a function?
(If you really mean "what happens?": any 'bool b = some_var;' will set 
'b' according to the C-idiom "if zero: 'false', otherwise 'true'".)
>   
>> (btw, wouldn't 'var != 0' actually be the proper semantic instead of 
>> playing with '!'s?)
>>     
>
> no because var could be a pointer for example...
>   
You mean because in that case it would be '!= NULL', do you? Sorry, do 
not see your point here.

regards,
Richard Knutsson

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ