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




Reply via email to