linux-kernel - RE: [RFC][PATCH] A generic boolean

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]

Date:	Thu, 20 Jul 2006 10:07:27 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Shorty Porty <getshorty_@...mail.com>
cc:	linux-kernel@...r.kernel.org, ricknu-0@...dent.ltu.se
Subject: RE: [RFC][PATCH] A generic boolean

>[...]
>from the compiler's standpoint. Function that return 'true' for an integer
>type (as opposed to a C++ standard-type bool) should be tested like
>
>  if(SomeFunction())
>
>or
>  if(!SomeFunction())
>
>instead of testing for equality
>
>  if(SomeFunction() == TRUE)
>of
>  if(SomeFunction() == FALSE)
>
>as the former (IMO) is as readable, if not more readable as the latter

Full ACK. What currently bugs me is that there are code places which 
"violate" your suggestion in a different way, i.e.

 void *foo = null_or_not_null_that_is_the_question();
 ...
 if(foo)
      do_bar();

vs

 if(foo == NULL)

>, and it's likely to get optimised better.

Unlikely that it will be better, as the compiler knows that bar() returns 
bool, testing it against TRUE or FALSE does not make a difference to
using "bar()" or "!bar()" respectively.

But I agree. The "!" operator was invented *for a reason*, so we do not 
need ==false.

>That and someone might give true AND return a status by returning neither 
>0 or 1, in which case 

In that case you cannot work with bools at all, because they are not 
guaranteed to be big enough for status codes. Here, 'int' comes into play.
And then func_return_int()==TRUE/FALSE seems strange anyhow. That's like

>> > If this is the case, then wouldn't "long" be preferable to "int"?
>
>Meh, it's all the same.

On x86, it is not. But x86_64 has int=4 bytes and long=8 bytes.
What's wasted is probably the cacheline due to a longer immediate 
integer in the instruction. SPARC64 for example is even more sensitive:
also has int=4 and long=8, but generates a lot more instructions for 'long' 
data shuffling than for 'int', because it has a small instruction size.
And also start to think of 'long long' (resp. int64_t) used somewhere [in 
code] on x86 -- also needs extra ops because the regs are not wide enough.

Jan Engelhardt
-- 
-
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/