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 13:53:27 +1000
From:	"Shorty Porty" <getshorty_@...mail.com>
To:	<linux-kernel@...r.kernel.org>
Cc:	<ricknu-0@...dent.ltu.se>
Subject: RE: [RFC][PATCH] A generic boolean

Someone showed code like

  _Bool foo = 42;

and if we were to make the compiler warn about it that would mean we are
basically trying to change/manipulate the standard (I'm guessing). It's
probably not in the standard because it's such a moot point. However if we
were to use

  if(foo)
  {
    ...
  }

we'd see it was true. That's because 
  FALSE == 0
and
  TRUE == !FALSE (i.e. any value that isn't 0)

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, and
it's likely to get optimised better. That and someone might give true AND
return a status by returning neither 0 or 1, in which case 

  if(... == TRUE)

would fail, as TRUE == 1.

And just as a note, you really should read the documentation (at least once)
for any function you use, and therefore know if it returns {FALSE, TRUE, ...
, TRUE} or {OK, ERR1, ERR2, ..., ERRn}

> > If this is the case, then wouldn't "long" be preferable to "int"?

Meh, it's all the same. I don't think 3 wasted CPU cycles is going to worry
anyone too much. Hell, sometimes int IS long, though I might be wrong there.

P.S. First post! Hello everybody.
-
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/