In this precise case, this is for an RTOS called INTEGRITY, which does 
define true and false as macros. The compiler is the vendor compiler 
(Green Hills), but the definition conflicting with Python's definition 
is comiung from the system header.
Note, the issue still remains outside this context.
>> Using stdbool.h when it is available will ensure bool is defined as a
>> type following the correct definition, which may or may not be an enum
>> depending on the compiler.
>>     
>
> But would that help in any way with respect to above compilers?
> If they don't follow the C standard, why should they provide stdbool.h?
>   
That's not the point.
If stdbool is not available, C99 still defines false and true as macros.
If stdbool is available, then most compilers will define false and true 
as macros. This includes Green Hills' compiler, but more importantly gcc 
as well.
Look at 
http://gcc.gnu.org/viewcvs/trunk/gcc/ginclude/stdbool.h?revision=130805&view=markup 
for the current definition of stdbool.h in gcc.
Look at 
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.html 
for a definition of how false, true and _Bool should be defined.
In both cases, if stdbool was included by any system header in the 
future, that would conflict with your current definition.
>> Even when using gcc, stdbool.h is here to define bool in C language, so
>> why not use it ?
>>     
>
> Because we cannot *rely* on stdbool.h being present. Therefore,
> inclusion of stdbool.h must be conditional, with a fallback definition
> if stdbool.h is absent, and it thus complicates the source code of
> Python, with no gain whatsoever.
>   
This is the main reason why I added the conditional in the code, so that 
for compilers that do not have a definition everything will work fine, 
and for those who have, then it's doing the right and expected thing.
But actually, you're right, the line should be completely eliminated, 
and replaced with the following :
typedef unsigned char _Bool;
#define bool _Bool
#define true 1
#define false 0

Btw, there are already a number of fallback definitions in Python.h and 
such. This one is another portability issue, just adding to the others. 
stdbool.h is a standard facility created to help portability, so again, 
why not use it ?

I can post an updated patch if you want.

Do you agree with these changes then?
--Rolland
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2497>
> __________________________________
>