stdbool.h does not define _Bool when included by C++ code

stdbool.h does not define _Bool when included by C++ code

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hi,

I noticed an issue with the musl headers when installing compiler-explorer for RISC-V. Try compiling this code with g++ and musl's stdbool.h

	- https://cx.rv8.io/g/Bc3AwY <https://cx.rv8.io/>

Compiler explorer uses the C++ front-end to the compiler by default

It seems the musl stdbool.h defines bool in terms of _Bool for C, but does not define _Bool in terms of bool for C++.

The gcc stdbool.h header handles both conditions and when included by C++ code it has #define _Bool bool but notes that it is a GNU extension.

My workaround was to delete the musl stdbool.h so that the GCC version is included, but it seems the header could work for C code passed through the C++ front-end with a small patch (attached). The other musl headers seem to support C++, so I think it might be nice to fix stdbool.h for C code compiled through the C++ front-end. Of course C++ code needs casts on malloc and there are several other differences such as new reserved words, however for the most part, a lot of C code can compile using the C++ front-end.

Michael


[-- Attachment #2.1: Type: text/html, Size: 1767 bytes --]

[-- Attachment #2.2: musl-stdbool-cplusplus.patch --]
[-- Type: application/octet-stream, Size: 267 bytes --]

diff --git a/include/stdbool.h b/include/stdbool.h
index a9d7ab7..06742f9 100644
--- a/include/stdbool.h
+++ b/include/stdbool.h
@@ -7,6 +7,10 @@
 #define false 0
 #define bool _Bool
 
+#else
+
+#define _Bool bool
+
 #endif
 
 #define __bool_true_false_are_defined 1

[-- Attachment #2.3: Type: text/html, Size: 233 bytes --]

Re: stdbool.h does not define _Bool when included by C++ code

[Rich Felker]

On Fri, Jul 28, 2017 at 10:21:10PM +1200, Michael Clark wrote:
> Hi,
> 
> I noticed an issue with the musl headers when installing
> compiler-explorer for RISC-V. Try compiling this code with g++ and
> musl's stdbool.h
> 
> 	- https://cx.rv8.io/g/Bc3AwY <https://cx.rv8.io/>
> 
> Compiler explorer uses the C++ front-end to the compiler by default
> 
> It seems the musl stdbool.h defines bool in terms of _Bool for C,
> but does not define _Bool in terms of bool for C++.
> 
> The gcc stdbool.h header handles both conditions and when included
> by C++ code it has #define _Bool bool but notes that it is a GNU
> extension.

I see; this is probably why I wasn't aware of it. I don't think it
would be objectionable to add.

Rich

Re: stdbool.h does not define _Bool when included by C++ code

[Szabolcs Nagy]

* Michael Clark <michaeljclark@mac.com> [2017-07-28 22:21:10 +1200]:
> It seems the musl stdbool.h defines bool in terms of _Bool for C, but does not define _Bool in terms of bool for C++.
> 
> The gcc stdbool.h header handles both conditions and when included by C++ code it has #define _Bool bool but notes that it is a GNU extension.
> 

ideally c++ would support all c keywords since c++ programmers
expect c headers to be valid c++ and new c keywords are in the
implementation namespace (except restrict in c99).

then _Bool, _Noreturn, etc in declarations would work in c++
(and it would be a conforming c++ implementation).

c code will use _Bool without including stdbool.h, so defining
it in stdbool.h does not help most uses of _Bool.

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.

Re: stdbool.h does not define _Bool when included by C++ code

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

Hello,

On Mon, 31 Jul 2017 11:18:28 +0200 Szabolcs Nagy <nsz@port70.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.

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

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.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: stdbool.h does not define _Bool when included by C++ code

[Michael Clark]

> On 31 Jul 2017, at 9:46 PM, Jens Gustedt <jens.gustedt@inria.fr> wrote:
> 
> Hello,
> 
> On Mon, 31 Jul 2017 11:18:28 +0200 Szabolcs Nagy <nsz@port70.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.

Re: stdbool.h does not define _Bool when included by C++ code

[Rich Felker]

On Tue, Aug 01, 2017 at 09:06:01AM +1200, Michael Clark wrote:
> 
> > On 31 Jul 2017, at 9:46 PM, Jens Gustedt <jens.gustedt@inria.fr> wrote:
> > 
> > Hello,
> > 
> > On Mon, 31 Jul 2017 11:18:28 +0200 Szabolcs Nagy <nsz@port70.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.

Compiling C code with a C++ compiler is utterly wrong, and will fail
in more subtle ways; erroring out early seems much more desirable. C
is not a subset of C++, and even the syntax that's in the intersection
of both languages is semantically different between them.

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

Adding -xc to command line fixes this. I've also requested Matt
Godbolt add a first-class language selection choice somewhere and I
thought he was going to do it, but I don't see it yet.

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

If this works, it's by chance, and there's no guarantee that it will
continue to work. There are definitely incompatibilities using gcc's
other std*.h headers with musl; certain include orders will yield
multiple or conflicting definitions or other issues. stdbool.h is
probably simple enough for now that it's not affected.

> It’s essentially discouraging C++ users who want more conformity
> with C.

I'm not entirely opposed to the proposed change if it eases adoption
and integration issues, but I'm skeptical that it really does, and I
do think it's something of a misfeature. Pretending a C++ compiler can
compile C hides bugs.

Rich

Re: stdbool.h does not define _Bool when included by C++ code

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Hello,

On Mon, 31 Jul 2017 21:31:22 -0400 Rich Felker <dalias@libc.org> wrote:

> On Tue, Aug 01, 2017 at 09:06:01AM +1200, Michael Clark wrote:
> >   
> > > On 31 Jul 2017, at 9:46 PM, Jens Gustedt <jens.gustedt@inria.fr>
> > > wrote:
> > > 
> > > Hello,
> > > 
> > > On Mon, 31 Jul 2017 11:18:28 +0200 Szabolcs Nagy <nsz@port70.net>
> > > wrote: 
>  [...]  
> > > 
> > > 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.  
> 
> Compiling C code with a C++ compiler is utterly wrong, and will fail
> in more subtle ways; erroring out early seems much more desirable. C
> is not a subset of C++, and even the syntax that's in the intersection
> of both languages is semantically different between them.

I agree, and I should have been more precise for the use case where
this actually makes sense. The only compatibility between C an C++
that is ensured is ABI compatibility. And here what I said above is a
reasonable way to write *header* files that can be included by both
languages. So such a header is *not* simply "C code that is compiled
as C++". There are several syntax problems for such headers, simple
ones as _Bool, but also _Noreturn, _Static_assert, and more difficult
ones as _Atomic or enumeration types ...

Such a header has to be carefully designed to fit to both
languages. Placing __cplusplus ifdef's into some of the headers could
be a strategy to ease the pain. Defining _Bool and stuff in some way
for C++ would just be pushing things under the carpet and hide
difficulties that reduce awareness of the problem.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]