From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: stdbool.h does not define _Bool when included by C++ code
Date: Mon, 31 Jul 2017 21:31:22 -0400 [thread overview]
Message-ID: <20170801013122.GC1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <53FF0182-D2D6-4D9D-9E99-5C9848A2A184@mac.com>
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
next prev parent reply other threads:[~2017-08-01 1:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 10:21 Michael Clark
2017-07-28 13:01 ` Rich Felker
2017-07-31 9:18 ` Szabolcs Nagy
2017-07-31 9:46 ` Jens Gustedt
2017-07-31 21:06 ` Michael Clark
2017-08-01 1:31 ` Rich Felker [this message]
2017-08-01 7:24 ` Jens Gustedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170801013122.GC1627@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).