This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: stdbool support
Type: compile error Stage: resolved
Components: Build Versions: Python 3.0, Python 2.6, Python 2.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: loewis, r.david.murray, rolland
Priority: normal Keywords: patch

Created on 2008-03-27 14:37 by rolland, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python_stdbool_20080327.diff rolland, 2008-03-27 14:37
Messages (7)
msg64594 - (view) Author: Rolland Dudemaine (rolland) Date: 2008-03-27 14:37
For better portability, it is good to support stdbool.h when it exists.
This prevents a potential issue when compiling asdl.c.
Patch attached.
msg64605 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-03-27 20:28
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?
msg64610 - (view) Author: Rolland Dudemaine (rolland) Date: 2008-03-27 23:55
Some compilers define false and true as macros.
When doing this, the definition in asdl.h (included from asdl.c) which 
is originally :
typedef enum {false, true} bool;
therefore becomes :
typedef enum {0, 1} bool;
which is non-sensical.
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.
Even when using gcc, stdbool.h is here to define bool in C language, so 
why not use it ?

--Rolland

Martin v. Löwis wrote:
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> 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?
>
> ----------
> nosy: +loewis
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2497>
> __________________________________
>
msg64615 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-03-28 04:47
> Some compilers define false and true as macros.

Which compilers specifically? It sounds like a violation of the C
standard to do so, without stdbool.h being included.

> 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?

> 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.
msg64617 - (view) Author: Rolland Dudemaine (rolland) Date: 2008-03-28 07:25
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>
> __________________________________
>
msg64659 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-03-28 23:45
> If stdbool is not available, C99 still defines false and true as macros.

What do you mean by that? In C99, true and false are *not* defined in
a translation unit unless stdbool.h is included, see 7.16.

> If stdbool is available, then most compilers will define false and true 
> as macros.

*In* the header file, that is. C99 *requires* the implementation to
define true and false *only* in the header file, and *only* as
macros. Anything else would not be conforming to C99.

> In both cases, if stdbool was included by any system header in the 
> future, that would conflict with your current definition.

No system header should ever include stdbool.h; doing so would be
in violation of the standards.

> Do you agree with these changes then?

Not at all; I think the patch should be rejected.
msg84352 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-03-29 00:49
Since Martin said this should be rejected, I'm closing it rejected.
History
Date User Action Args
2022-04-11 14:56:32adminsetgithub: 46749
2009-03-29 00:49:57r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg84352

resolution: rejected
stage: resolved
2008-03-28 23:45:12loewissetmessages: + msg64659
2008-03-28 07:25:20rollandsetmessages: + msg64617
2008-03-28 04:48:00loewissetmessages: + msg64615
2008-03-27 23:55:23rollandsetmessages: + msg64610
2008-03-27 20:28:48loewissetnosy: + loewis
messages: + msg64605
2008-03-27 14:37:19rollandsettype: compile error
2008-03-27 14:37:11rollandcreate