Re: [PATCH] std-gnu23: new module

[Bruno Haible]

Paul Eggert wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00289.html>:
> +# Prefer GNU C23 to earlier versions.

This module does not have the intended effect: With a gcc 15 snapshot,
the 'configure' script of a gnulib testdir produces:

checking for /gnu-inst-gcc/15-20241113/bin/gcc option to enable C23 features... 
unsupported
checking for /gnu-inst-gcc/15-20241113/bin/gcc option to enable C11 features... 
none needed

I would have expected:

checking for /gnu-inst-gcc/15-20241113/bin/gcc option to enable C23 features... 
-std=gnu23

This comes from this piece of code:
> +
> +#include <stdbit.h>
> +static_assert (__STDC_ENDIAN_LITTLE__ != __STDC_ENDIAN_BIG__);
> +

which (in config.log) leads to:

conftest.c:74:10: fatal error: stdbit.h: No such file or directory
   74 | #include <stdbit.h>
      |          ^~~~~~~~~~

This test for <stdbit.h> is not useful, because <stdbit.h> is part of
the C library, not part of the compiler.

  * It has the effect that even with the newest GCC and clang compilers,
    the test "for ... option to enable C23 features" will say "unsupported"
    on all glibc versions < 2.39 and on many other platforms.

  * It does not consider the possibility that the package might not require
    <stdbit.h> or might provide <stdbit.h> via the Gnulib module — since
    by the time 'configure' runs, the Gnulib module has not been built yet.

I would suggest to remove this part of the C23 test. I mean, the test for C11
does not require <uchar.h> to be installed either.

Then, packages can make use of new C23 language features by requiring a
recent compiler on the target platform, but without requiring an entirely
recent OS with glibc on the target platform.

Bruno