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
