[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bool and C23
From: |
Bruno Haible |
Subject: |
Re: bool and C23 |
Date: |
Fri, 09 Sep 2022 11:14:21 +0200 |
Paul Eggert wrote:
> To help move ahead on this, I propose the attached patches to Gnulib.
> They use a simpler version of the Autoconf macro, named gl_C_BOOL to
> avoid collision with any future improvements to Autoconf. My hope is
> that gl_C_BOOL can be renamed to AC_C_BOOL, or something like that. The
> idea is that AC_C_BOOL assumes C99 or later; if you want to port to
> pre-C99 (which pretty much nobody does these days), you can use the
> Gnulib stdbool module.
>
> The first patch adds a Gnulib module c-bool, which acts like the
> existing Gnulib module stdbool except it supports C23-style bool (no
> include file) instead of C99-style bool.
I have two objections against this patch:
* A technical one: In
<https://lists.gnu.org/archive/html/autoconf/2022-08/msg00009.html>
Zack and I agreed that the AH_VERBATIM code should be of the form
#ifndef __cplusplus
...
#endif
Also, in <https://lists.gnu.org/archive/html/autoconf/2022-08/msg00001.html>
I suggested to ensure that the '#include <stdbool.h>' goes to the end of
config.h. IIUC, a way to do this is to replace
AH_VERBATIM([bool], [...code...])
with
AH_VERBATIM([zzbool], [...code...])
* A major design objection: While from the Autoconf perspective, it is natural
to have two macros AC_HEADER_STDBOOL and AC_C_BOOL, from the Gnulib
perspective it is not good to have two modules 'stdbool' and 'c-bool'.
The problems that I'm seeing are:
- How do we explain it to the Gnulib users?
You have written this in the doc:
"If your code needs to be portable to pre-C99 platforms,
it needs to also use the @code{stdbool} module."
So the user needs to think about whether to use 'stdbool',
or 'c-bool', or both (!).
- So far, we have two different modules when there are two
conflicting standards. For example, getopt-posix vs. getopt-gnu.
But it is easy to explain: "If you want getopt to behave like
specified in POSIX, use getopt-posix. If you want it to behave
like glibc, use getopt-gnu." But different modules for different
versions of the same standard? We have avoided this so far.
- Different modules for different ISO C versions also means that
every package would need to migrate at some point. Namely, swap
'stdbool' against 'c-bool' in the autogen.sh script / bootstrap.conf /
local gnulib module dependencies. It would be a disgrace to force
this on our users.
- We would need to make sure that these two modules don't interfere.
For example, if there are two gnulib-tool invocations, like in
https://www.gnu.org/software/gnulib/manual/html_node/Multiple-instances.html ,
e.g. 'c-bool' used by a library and 'stdbool' by the program,
we would need to ensure that things go well.
I would suggest to keep *one* module, and keep it named 'stdbool'.
Its meaning will be "provide bool, true, false according to the standards".
It can invoke AC_HEADER_STDBOOL and AC_C_BOOL under the hood.
The important point is that the migration from older to newer ISO standard
versions is transparent (not troublesome) for the Gnulib user.
> The second patch is mostly mechanical: it changes the other Gnulib
> modules to prefer c-bool to stdbool.
Once this patch is reduced to modifying only lib/ and tests/ — no changes to
modules/ —, I volunteer to test it
a) on various existing platforms,
b) on clang 15, which has "false and true first-class language features"
(see https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html ).
Bruno
- Re: bool and C23, Paul Eggert, 2022/09/09
- Re: bool and C23,
Bruno Haible <=
- Re: bool and C23, Paul Eggert, 2022/09/10
- Re: bool and C23, Bruno Haible, 2022/09/10
- Re: bool and C23, Paul Eggert, 2022/09/10
- Re: bool and C23, Bruno Haible, 2022/09/10
- Re: bool and C23, Bruno Haible, 2022/09/10
- Re: bool and C23, Bruno Haible, 2022/09/18
- Re: bool and C23, Paul Eggert, 2022/09/18
- Re: bool and C23, Bruno Haible, 2022/09/18