New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdbool support #46749
Comments
For better portability, it is good to support stdbool.h when it exists. |
Why does it improve portability to use stdbool.h when it exists? What is the potential issue with asdl.c that gets fixed with this patch? |
Some compilers define false and true as macros. --Rolland Martin v. Löwis wrote:
|
Which compilers specifically? It sounds like a violation of the C
But would that help in any way with respect to above compilers?
Because we cannot *rely* on stdbool.h being present. Therefore, |
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 I can post an updated patch if you want. Do you agree with these changes then?
|
What do you mean by that? In C99, true and false are *not* defined in
*In* the header file, that is. C99 *requires* the implementation to
No system header should ever include stdbool.h; doing so would be
Not at all; I think the patch should be rejected. |
Since Martin said this should be rejected, I'm closing it rejected. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: