[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
