RFC: booleans and the kernel
Quoted 1 line · Jeff Garzik
A small issue...
... bound therefore to generate the most discussion ...
Quoted 4 lines
C99 introduced
_Boolas a builtin type. The gcc patch for it went into cvs around Dec 2000. Any objections to propagating this type and usage of 'true' and 'false' around the kernel?
What concerns me is the question of casting. Will truth always cast to integer value 1 and falsehood always cast to integer value 0, and vice versa? If so then the bool type is a lot like a "bit" type would be if C had one, i.e., a very short integer variable limited to the values 0 and 1. If the casts are not guaranteed then bool is a lot like an enumerated type where the compiler is free to choose whatever representations it wants for truth and falsehood.
I assume the casts are guaranteed. E.g., I take it that the result of a logical comparison is considered to be of type bool, but that the following will increment val by 1 if a > b
val += (a > b)
In that case, perhaps it would be more perspicuous to define a "bit" type rather than a "bool" type, and to use 0 and 1 as its values rather than 'true' and 'false'. (A "bit" type would have all the advantages mentioned earlier by Peter Anvin
http://marc.theaimsgroup.com/?l=linux-kernel&m=101191106124169&w=2 .)
--
Thomas Hood
Quoted 5 lines · Thomas Hood
In that case, perhaps it would be more perspicuous to define a "bit" type rather than a "bool" type, and to use 0 and 1 as its values rather than 'true' and 'false'. (A "bit" type would have all the advantages mentioned earlier by Peter Anvin
http://marc.theaimsgroup.com/?l=linux-kernel&m=101191106124169&w=2 .)
in the hypothetical 'bit type' case:
bit n;
n = 2;printf("n = %d\n", n);
guess what ? n = 0
Xav