Messages in this thread | | | Date | Wed, 26 Jul 2006 21:00:20 -0700 | From | Paul Jackson <> | 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@sgi.com> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |