Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230531141858.GA4163@brightrain.aerifal.cx>
Date: Wed, 31 May 2023 10:18:59 -0400
From: Rich Felker <dalias@...c.org>
To: Joakim Sindholt <opensource@...sha.com>
Cc: musl@...ts.openwall.com
Subject: Re: [C23 divers headers 09/17] C23: update stdbool.h

On Wed, May 31, 2023 at 04:13:38PM +0200, Joakim Sindholt wrote:
> On Wed, 31 May 2023 15:53:37 +0200, Jā‚‘ā‚™ā‚› Gustedt <jens.gustedt@...ia.fr> wrote:
> > Joakim,
> > 
> > on Wed, 31 May 2023 14:58:52 +0200 you (Joakim Sindholt
> > <opensource@...sha.com>) wrote:
> > 
> > > Implementations may also provide macros in addition to
> > > > the keywords, so we do that because some user code may rely on
> > > > these.
> > 
> > Is this not explanation enough?
> > 
> >   Implementations may also provide macros in addition to the keywords,
> >   so we do that because some user code may rely on these.
> 
> I guess I just don't see the point. This is allowed for literally every
> symbol in libc.

I think the point is avoiding stupid things happening when programs
(or cursed library headers they're using, iirc including nncurses) do
things like:

#ifndef bool
#define bool int
#endif

If the application itself is including stdbool.h explicitly, I would
not expect it to do such a thing. But it might only be including
stdbool.h indirectly via the headers for a third party library it's
using. C11 introduced the notion that you can test for the presence of
bool with #ifdef, and it seems unfortunate to turn around and break
that.

Rich

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.