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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 26 Jul 2006 21:00:20 -0700
From:	Paul Jackson <pj@....com>
To:	Josef Sipek <jsipek@....cs.sunysb.edu>
Cc:	ricknu-0@...dent.ltu.se, linux-kernel@...r.kernel.org,
	akpm@...l.org, jeff@...zik.org, adobriyan@...il.com,
	vlobanov@...akeasy.net, jengelh@...ux01.gwdg.de,
	getshorty_@...mail.com, pwil3058@...pond.net.au, mb@...sch.de,
	penberg@...helsinki.fi, stefanr@...6.in-berlin.de,
	larsbj@...lik.net
Subject: Re: [RFC][PATCH] A generic boolean (version 6)

Josef wrote:
> You probably have said it before, but why do we need this?

Well, Richard should answer this, more than me.  He's the one who
braved this latest charge against a topic of much prior debate.

And I'm unsure what part of the above you wonder the reason for.

Ignoring all that ... my motivation is thus.

We've got umpteen ways of spelling and defining boolean types.  Code
would be more consistent, clear and clean if we had one way of spelling
it uniformly, through the kernel.  For example, Andrew's failed assault
on this topic in March was motivated by a build failure, when a couple
of variant spellings collided.

Some of us, apparently a majority, though the minority includes some
respected and vocal citizens of long standing, find it clearer to
explicitly code boolean types using some variant of bool/false/true,
rather than implicitly in the traditional C style of int/0/1.

C99 has added a native _Bool, along with a stdbool.h that defines
bool/false/true, and C++ has always had a native bool/false/true type.
So, despite Andrew's attempt in March to standardize on spelling
these values as FALSE/TRUE, the C99 spelling of false/true seems to
be carrying the day.

With C99's _Bool and a typedef of 'bool' for _Bool, we have a gcc
supported (for some definition of support ;) 'bool'.

But we need either #defines or an enum to spell false and true.
Since the enum provides greater opportunities for type checking,
that appears to be winning the day.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.925.600.0401
-
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