[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <53FF0182-D2D6-4D9D-9E99-5C9848A2A184@mac.com>
Date: Tue, 01 Aug 2017 09:06:01 +1200
From: Michael Clark <michaeljclark@....com>
To: Jens Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: stdbool.h does not define _Bool when included by C++ code
> On 31 Jul 2017, at 9:46 PM, Jens Gustedt <jens.gustedt@...ia.fr> wrote:
>
> Hello,
>
> On Mon, 31 Jul 2017 11:18:28 +0200 Szabolcs Nagy <nsz@...t70.net> wrote:
>
>> iow, this is either a minor gcc bug or a big fat c++ defect
>> depending on how you look at it, the libc cannot fix this
>> properly, just emulate the broken nonsense in gcc stdbool.h
>> that nobody should rely on.
>
> Basically stdbool.h is already a header to accomodate C++ usage of
> bool, false and true to C. I makes not much sense to include this
> in C++ code.
It’s useful exactly for the case where you have C code in your C++, which is why I suspect GCC has the condition in its version of stdbool.h
> I think that applications that want to be shure that their code
> compiles for both should use "bool" and should do
>
> #ifndef __cplusplus
> # include <stdbool.h>
> #endif
I think you’re missing the point. C code can use _Bool and this can be put through the C++ front-end. Compiler explorer does this by default, and the GCC and glibc headers already have the fix, which is #define _Bool bool (in the patch) for the case where C code is fed in to the C++ front end.
Have a look at gcc’s stdbool.h
Notice that compiler has all the signs that it is actually C, including using gcc and clang in the compiler labels instead of g++ and clang++
- https://godbolt.org/g/rhEZCx
There are both C and C++ users who use compiler explorer, and it seems the C users will have to add casts to malloc return values and what not. Notice the dissasembly has de-mangled type-safe linkage. It’s useful because you can see the arity of the function in compiler explorer disassembly.
> We can put more comfort into this by lifting this #ifndef/#endif stuff
> to the contents of the file, if people really want this. But code that
> relies on this would not be guaranteed to be portable.
>
> Using "bool" by means of the header is the intended usage, these
> attrocities such as _Bool, _Noreturn etc are only there for backwards
> compatibility. Hopefully at least some of them will be phased out in
> the future.
>
> I think we should not encourage the usage of these keywords in
> application code unless this is needed for backwards compatibility,
> nor should we try to impose their possible usage into other languages.
In any case the workaround is to rm PREFIX/include/stdbool.h so that the libgcc version gets included.
It’s essentially discouraging C++ users who want more conformity with C.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
