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