Re: [RFC][PATCH] A generic boolean (version 6)

[Paul Jackson <pj@sgi.com>]

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@sgi.com> 1.925.600.0401