[mbell]

Consider a simple bit mask operation, assume 8 bit ints for the sake of brevity:

Prior to C99, assuming you use the mentioned typedef for bool:

    bool a = someInt & 0x02

'a' will be 0x02 if the bit is set.

In C99, bool is aliased to _Bool and if the flag is set, the above code will result in 'a' being 0x01 because of C99's requirements for type conversion.

To accurately get the same behavior prior to C99, you can add !!, e.g.:

    bool a = !!(someInt & 0x02)  //'a' is now 0x01 when the bit is set.

[Silhouette]

Most, if not all, of the problems people are describing in this discussion come down to trying to assign something that isn't a boolean value to a variable of boolean type, and expecting it to do something sensible. I don't see how this is ever going to have a happy ending.

If you had written

    bool a = (someInt & 0x02) == 0x02

or something similarly clear and unambiguous, nothing odd would happen, even in C.

(Edit: OK, that's not strictly true, because of the operator precedence order. It's never made sense to me that integer arithmetic operators have higher precedence than comparisons but bitwise logical operators have lower precedence, so if you remove the parentheses above then the resulting code doesn't do what you'd expect. I suppose this is because I'm looking at the problem as if comparison operators return a proper boolean value rather than an integer, and the ordering we've wound up with in C dates from a historical oddity about 40 years ago.)

The underlying problem with booleans in C99, as Linus and others have been saying, is that the language doesn't actually enforce basic type safety, so cases like your first example

    bool a = someInt & 0x02

that should result in a type error are allowed through, and with odd results: how does it make any sense for a boolean variable to have an integer value like 0x01 or 0x02?

Then programmers who relied on such odd results wind up writing horrific code like your second example

    bool a = !!(someInt & 0x02)

where fudge factors build on top of distortions to make the old hacks work.

And then we wonder why in 2013 we still have widely used, essential software that is riddled with security flaws and crash bugs. :-(

[caf]

The reason that & and | have lower precedence than the comparison operators is indeed historical - it's because the earliest versions of the language didn't have the logical boolean operators && and ||, so the bitwise & and | operators stood in for them. The lower precedence meant that you could write:

  if (x == 1 & y == 2) {

..and have it do what you meant. This became a bit of a wart when the && and || operators were introduced (still well before ANSI standardisation), but it was considered that changing it would have broken too much existing code.

[noselasd]

    bool a = someInt & 0x02;

is perfectly fine in C99. 0 converts to false, non-zero converts to 1 when assigning to a _Bool.

What's not fine is people creating their own compatibility booleans where they define true as 1, as that would indeed break(rather odd..) code such as

    bool a = someInt & 0x02;
    if (a == true) 

If the bool above is not the C99 _Bool, but just a typedef to another integer type, you end up with if(0x02 == 1) evaluating to false.

[crucini]

> Then programmers who relied on such odd results wind up writing horrific code like your second example

What's horrific about that? Would it be better if we had:

    #define to_bool(_X) !!(_X)
    ...
    bool a = to_bool(someInt & 0x02);

[andrewcooke]

but this - and other examples here - seem unfair, in that they are blaming _Bool for working correctly (consistently, logically) in cases where people were previously doing dumb things.

if you rely on something called "bool" being 0x02 you're going to have a bad time. that's hardly C99's fault.

your last line of code is what i would write, effectively, if i needed to compare booleans. it seems to me that _Bool is an improvement because, pre-C99, if i forgot the !! dance somewhere, i likely had a bug. with _Bool things just work.

(disclaimer, as with other reply here - still trying to get a grasp on this, so may be saying something stupid myself).

[mbell]

I don't really disagree, but Linus's point, which I agree with, is that C99's implementation is 'better' but is still pretty bad, i.e. 'bool' is still a mask for 'int' and as a result array's of bools aren't what they should be: bit arrays, directly serializing a bool is still sending out an entire int of data, etc. The 'improvement' in C99 isn't worth the broken code that will result from the subtle differences.

It's also worth considering in context that a lot of the code which will run into problems with these small differences is low level OS/driver code that often deals with a lot of bit flags and bit manipulation in general. When your trying to fit a web server into 3800 _bytes_ of ram on an 8 bit microcontroller, 'doing dumb things' becomes 'being inventive'.