Re: bool and C23

[Bruno Haible]

Zack Weinberg wrote:
> >   * In C++ mode,
> […]
> >     [cstdbool may include] various OS stuff, and should therefore be
> >     avoided when possible. Since a compilation unit cannot be ISO C 23
> >     and C++ at the same time, it is easy to achieve: Wrap the new
> >     config.h additions in
> >       #ifndef __cplusplus
> >       ...
> >       #endif
> 
> Yes, this was already my plan.

Good.

> Do you think it’s worth mentioning
> this issue in Autoconf’s documentation (it already says “stdbool.h
> should not be included from C++” but not why).

Not worth mentioning. The sample code that you have included for the
no-autoheader case already avoids include <stdbool.h> in C++ mode.
There's no need to go beyond that.

> >   * In C mode: […] it is OK to #include <stdbool.h>, since it
> >     does not include header files with function declarations, only
> >     header files with macro definitions.
> 
> We _could_ still get errors from -Wredundant-decls -Werror or
> equivalent, but I think that’s probably okay to live with.

I agree. Generally options like -Wredundant-decls may spew many more warnings
on non-glibc systems than on glibc systems.

> >   - Determine GL_GENERATE_STDBOOL_H as in gnulib/m4/stdbool.m4,
> 
> It looks like the only thing gl_STDBOOL_H does, that my current draft
> of AC_C_BOOL doesn’t do, is refuse to use an existing <stdbool.h> from
> C++ on Solaris.  Given that my current draft _never_ uses <stdbool.h>
> from C++, I think we can just scrap that part.

I agree. This part of gnulib/m4/stdbool.m4 has the purpose of providing
an <stdbool.h> that works both in C and C++ mode with that particular
Solaris 10. Your goal is a different one: provide a config.h snippet
that defines 'bool', 'false', 'true' according to the standards. You can
therefore ignore that Solaris 10 cc problem.

> Looking at the existing Gnulib code, though, suggests another possible
> reason why we might need the fallback code to `signed char` (or
> Gnulib’s enumeration): allegedly C99-compliant compilers whose Boolean
> implementation is buggy.  My AC_C_BOOL preserves the existing test for
> a buggy Boolean type, from AC_CHECK_HEADER_STDBOOL, so, if we do as
> Paul suggests and make configure error out when there’s no usable
> Boolean, that will hard reject those compilers as well.  I’m fine with
> that.  Are you fine with that?

Given that these compilers are more than 15 years old, I'm fine with it.

Bruno