[cc'ing this to bug-gnulib since it's Gnulib-relevant. This follows up
on the thread starting here:
https://lists.gnu.org/r/autoconf/2022-08/msg00003.html
]
On 8/21/22 07:59, Zack Weinberg wrote:
> @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?
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.
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.
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. Bruno would know better than I.
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.
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.
> 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.
In theory it might be more complicated. This is because one possibility
is that 'true' is defined by the system's <stdbool.h> which says
"#define true (!0)". The C standard allows this. I didn't want the
Autoconf manual to promise more than what the C standard promises.
> @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.
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.
