Richard wrote:
> * removed the #undef false/true and #define false/true
Good - thanks.
+enum {
+ false = 0,
+ true = 1
+};
My inclination would have been to write this as the more terse:
+enum { false, true };
But I suspect yours is better, as some readers would not be
confident that the terse form made false == 0 and true == 1.
> a real patch (hoping for inclusion) tomorrow.
Good.
I'm delighted that this favors "true, false and bool",
over "TRUE, FALSE and various spellings of BOOLEAN".
Fun stuff to do in the future:
Convert test_bit() and various other test_*() and
atomic_*() operators to return bool.
Convert many TRUE/FALSE to true/false, in a patch of
similar size to Andrew's March 2006 patch entitled:
"[patch 1/1] consolidate TRUE and FALSE".
Convert a variety of spellings of BOOLEAN to "bool".
Convert routines and variables using the old C
convention of int/0/1 for boolean to the
new bool/false/true.
How do we detect breakage that results from converting
an apparent boolean to these values, when the
code actually worked by using more than just
values 0 and 1 for the variable in question?
How do we detect any breakage caused by possible changes
in the sizeof variables whose type we changed?
Various sparse and/or gcc checks that benefit from
knowing the additional constraints on bool types.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
