Skip to content
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

Closed
rolland mannequin opened this issue Mar 27, 2008 · 7 comments
Closed

stdbool support #46749

rolland mannequin opened this issue Mar 27, 2008 · 7 comments
Labels
build The build process and cross-build

Comments

@rolland
Copy link
Mannequin

rolland mannequin commented Mar 27, 2008

BPO 2497
Nosy @loewis, @bitdancer
Files
  • python_stdbool_20080327.diff
  • 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:

    assignee = None
    closed_at = <Date 2009-03-29.00:49:57.183>
    created_at = <Date 2008-03-27.14:37:11.373>
    labels = ['build']
    title = 'stdbool support'
    updated_at = <Date 2009-03-29.00:49:57.159>
    user = 'https://bugs.python.org/rolland'

    bugs.python.org fields:

    activity = <Date 2009-03-29.00:49:57.159>
    actor = 'r.david.murray'
    assignee = 'none'
    closed = True
    closed_date = <Date 2009-03-29.00:49:57.183>
    closer = 'r.david.murray'
    components = ['Build']
    creation = <Date 2008-03-27.14:37:11.373>
    creator = 'rolland'
    dependencies = []
    files = ['9875']
    hgrepos = []
    issue_num = 2497
    keywords = ['patch']
    message_count = 7.0
    messages = ['64594', '64605', '64610', '64615', '64617', '64659', '84352']
    nosy_count = 3.0
    nosy_names = ['loewis', 'rolland', 'r.david.murray']
    pr_nums = []
    priority = 'normal'
    resolution = 'rejected'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue2497'
    versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']

    @rolland
    Copy link
    Mannequin Author

    rolland mannequin commented Mar 27, 2008

    For better portability, it is good to support stdbool.h when it exists.
    This prevents a potential issue when compiling asdl.c.
    Patch attached.

    @rolland rolland mannequin added build The build process and cross-build labels Mar 27, 2008
    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Mar 27, 2008

    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?

    @rolland
    Copy link
    Mannequin Author

    rolland mannequin commented Mar 27, 2008

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


    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Mar 28, 2008

    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.

    @rolland
    Copy link
    Mannequin Author

    rolland mannequin commented Mar 28, 2008

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


    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Mar 28, 2008

    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.

    @bitdancer
    Copy link
    Member

    Since Martin said this should be rejected, I'm closing it rejected.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    build The build process and cross-build
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant