Question

I just stumbled across an assert that failed, as it compared false to the returntype of a function, as the function itself returned a bool and the assert checked not only the value, but also the type of the returnvalue to match the one of false, to guarantee, that a bool is returned.

Now the problem is that C99 defines bool as _Bool and _Bool is even not necessarily the same size as int (in fact, in my experience, on most platforms nowadays, it is often the same size as unsigned char), not to talk about being the same type (which is actually impossible, as _Bool is a builtin type of the language in C99), but defines false and true as 0 and 1 without any typecast and preprocessor definitions without a typecast will default to int.

If C99 would instead define false and true as ((bool)0) and ((bool)1), they would always be of type bool, no matter, how _Bool is defined.

So is there a good reason to have them always defined as ints, even when bool is not an int on that platform or is this just a bug in the language that should be fixed with C1x?

Answer 1

false and true are defined as the integer constants 0 and 1 respectively, because that’s exactly what the C99 standard specifies in section 7.16 :

< SNIP >

The remaining three macros are suitable for use in #if preprocessing directives. They
are

true

which expands to the integer constant 1,

false

which expands to the integer constant 0, and

< SNIP >

EDIT : as the comments below indicate, it seems I slightly misinterpreted the question, and I should have provided the reason the standard specifies it like that. One reason I can think of, is that true and false are supposed to be usable in #if preprocessing directives (as the quote from the standard mentions).

The reason ((bool) 0) or ((bool) 1) won’t work in #if preprocessing directives, is because the standard doesn’t allow it. In section 6.10.1 it says :

The expression that controls conditional inclusion shall be an integer constant expression
except that: it shall not contain a cast;