Thanks for working on this.
One general comment: some names use 'bool', while others use 'boolean'.
I suggest sticking with 'bool' for consistency.
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".
> @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. In the bool
department I know of no active pre-C99 C platforms, and Autoconf need
not support museum pieces. Omitting this unnecessary complexity will
save our users time because they won't have to worry about it.
In other words, AC_C_BOOL can simply behave as if IF-REQUIRED is true.
This will simplify Autoconf's documentation and use. If a need ever
turns up for a variant of AC_C_BOOL that supports pre-C99 we can invent
a new macro like AC_C_BOOL_OPTIONAL to do that; but I hope it won't be
needed.
Simplifying AC_C_BOOL means we won't need C_HAVE_BOOLEAN_TYPE (or
HAVE_BOOLEAN_TYPE; don't quite follow why there's both) and we don't
need C_TYPE_FOR_BOOL (or is that C_BOOL_DEFINITION?). And we don't need
to document ac_cv_c_boolean_type=no. And we can simplify the example of
preprocessor logic from 17 lines to:
#include "config.h"
#if defined C_NEED_STDBOOL_H && !defined __cpluplus
# include <stdbool.h>
#endif
> 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,".
> @command{configure} will arrange to make @code{bool} a synonym for
> @code{int},
Change "@code{int}" to "a type that promotes to @code{int}".
