From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11767 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: stdbool.h does not define _Bool when included by C++ code Date: Mon, 31 Jul 2017 21:31:22 -0400 Message-ID: <20170801013122.GC1627@brightrain.aerifal.cx> References: <20170731091828.GA15263@port70.net> <20170731114623.0a449442@inria.fr> <53FF0182-D2D6-4D9D-9E99-5C9848A2A184@mac.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1501551097 12173 195.159.176.226 (1 Aug 2017 01:31:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2017 01:31:37 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11780-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 01 03:31:33 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dcM20-0002td-OU for gllmg-musl@m.gmane.org; Tue, 01 Aug 2017 03:31:32 +0200 Original-Received: (qmail 7264 invoked by uid 550); 1 Aug 2017 01:31:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7243 invoked from network); 1 Aug 2017 01:31:35 -0000 Content-Disposition: inline In-Reply-To: <53FF0182-D2D6-4D9D-9E99-5C9848A2A184@mac.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11767 Archived-At: On Tue, Aug 01, 2017 at 09:06:01AM +1200, Michael Clark wrote: > > > On 31 Jul 2017, at 9:46 PM, Jens Gustedt wrote: > > > > Hello, > > > > On Mon, 31 Jul 2017 11:18:28 +0200 Szabolcs Nagy 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 > > #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