On Sat, Aug 20, 2022, at 4:20 PM, Paul Eggert wrote:
> Thanks for working on this.
>
> One general comment: some names use 'bool', while others use 'boolean'.
> I suggest sticking with 'bool' for consistency.
The intent here was to use 'bool' when referring specifically to the
C-family type name, and 'Boolean' with a capital B when talking about
the concept.
> On 8/19/22 15:22, Zack Weinberg wrote:
> > maybe if someone's using GCC for C but Apple's compilers for Objective-C.
>
> I wouldn't worry about this now. If it ever comes up, we can address it
> then with more information because we'll know from the bug report what
> the exact situation is. In the meantime we can say "don't do that".
Seems reasonable.
> > @defmac AC_C_BOOL (@ovar{if-required})
>
> How about if we omit the IF-REQUIRED parameter? It matters only to
> people who still want to port to pre-C99 compilers.
That does simplify things quite a bit. I didn't do it that way to
begin with because the Gnulib stdbool module is still catering to
pre-C99 compilers, and I want this to be a drop-in upgrade from that
as well as from direct use of AC_[CHECK_]HEADER_STDBOOL. 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?
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. Keeping C_BOOL_DEFINITION also means that it's simpler
to put the "optional" mode back if it turns out, after 2.72 comes out,
that we need it. The code for people not using autoheader becomes
#include "config.h"
#ifndef __cplusplus
# ifdef C_NEED_STDBOOL_H
# include <stdbool.h>
# elif defined C_BOOL_DEFINITION
# define bool C_BOOL_DEFINITION
# define false 0
# define true 1
# endif
#endif
which really isn't that bad IMHO.
> > Ensure that @code{false} and @code{true} are usable as integer
> constants that are equal to 0 and 1, respectively.
>
> Change "integer constants" to "integer constant expressions, suitable
> for use in #if preprocessing directives,".
I will add something about 'true' and 'false' working in #if but I
don't want to use the phrase "integer constant expression" because
that makes it sound like the macro expansion is more complicated than
just an integer literal.
> > @command{configure} will arrange to make @code{bool} a synonym for
> > @code{int},
>
> Change "@code{int}" to "a type that promotes to @code{int}".
This text will be dropped anyway if we drop the "optional" mode, but
your comment reminds me that I meant to ask you why the Gnulib stdbool
module uses "signed char" as the fallback underlying type for bool.
To me it seems not only abstractly incorrect (given that 1989 vintage
code tended to use 'int' when a Boolean was meant), but also actively
dangerous (because it will lead to unexpected integer promotion), to
use a type smaller than int as the fallback.
zw
