Please note consolidated reply to both Paul and Bruno.
On Sun, Aug 21, 2022, at 5:25 PM, Paul Eggert wrote:
> On 8/21/22 07:59, Zack Weinberg wrote:
>> Paul Eggert:
>>> Zack Weinberg:
>>>> @defmac AC_C_BOOL (@ovar{if-required})
>>>
>>> How about if we omit the IF-REQUIRED parameter?
>>
>> Taking out the "optional" mode will mean that regenerating the the
>> configure script of a package that uses the stdbool module, with
>> Autoconf 2.72, will quietly bump its minimum C compiler requirement
>> to C99. Are we okay with that?
>
> Yes, I think so. I believe Gawk was the last Gnulib-using project that
> wanted portability to C89, and Gawk dropped that requirement a few years
> ago.
OK, I’ll proceed on the assumption this is fine unless we hear
otherwise, and I’ll make sure both Autoconf NEWS and the manual make
the implications clear.
> More precisely, the idea is that in
> <https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html>
> we'd change "<stdbool.h>, assuming the stdbool module is used. See
> stdbool.h." to something like "bool, true, and false (perhaps via
> <stdbool.h>); see the bool module." The stdbool module would become
> obsolescent.
There isn’t a bool module right now, are you proposing to add one?
To be clear, I want to get to where _no_ Gnulib module is required for
bool; AC_C_BOOL by itself should be enough.
>> I think we still need C_BOOL_DEFINITION even if we make that change,
>> because apparently there exist(ed?) compilers that provide _Bool but
>> not stdbool.h.
>
> Apparently OS X had that problem as recently as 2018
> <https://github.com/carp-lang/Carp/issues/332> so I guess such a
> workaround would be helpful for some apps. I'm not sure Gnulib will need
> it though.
Again, AC_C_BOOL by itself is supposed to be all you need (in the
common case where autoheader is in use).
> Sure, but why can't the non-autoheader case define bool, false, and true
> instead of defining C_BOOL_DEFINITION? That will keep the code simpler
> for these people.
I don’t understand what you are suggesting here.
> one possibility
> is that 'true' is defined by the system's <stdbool.h> which says
> "#define true (!0)". The C standard allows this.
I don’t think it does? N1570 (C11-in-all-but-name) 7.18p3 says “`true`
expands to the integer constant 1” and “`false` expands to the integer
constant 0.” No leeway at all there. I don’t have my copy of C99 on
this computer, but I doubt it says anything different.
>> I meant to ask you why the Gnulib stdbool module uses "signed char"
>> as the fallback underlying type for bool.
>
> I don't recall exactly but I can imagine a couple of good reasons.
> First, it makes it more likely you'll get a type clash if you mistakenly
> confuse int for bool in function signature compiled by an older
> compiler. Second, it makes it less likely that there would be a clash if
> some code is compiled with a compiler that has a working bool of size 1
> (the most common implementation I think), whereas other code is compiled
> with Gnulib's substitute for bool.
Hm, OK, I guess. I’m still worried about undesirable integer
promotions but I guess those happen with _Bool used in arithmetic
expressions too (since it has the lowest possible integer conversion
rank).
On Sun, Aug 21, 2022, at 5:34 PM, Bruno Haible 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. 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).
> * 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.
> - 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.
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?
zw
