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
