bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How can Autoconf help with the transition to stricter compilation de


From: Zack Weinberg
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Sat, 12 Nov 2022 10:06:01 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Demi Marie Obenour <demiobenour@gmail.com> writes:
> On 11/10/22 15:19, Paul Eggert wrote:
>> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf 
>> supported K&R C, C89, C99, etc. At some point (I'm not sure when), 
>> Autoconf started requiring C89 or later. Is it now OK for Autoconf to 
>> require C99 or later, as far as bool is concerned? If so, that'll 
>> considerably simplify the ongoing maintenance hassle for bool.
>>
>> Requiring C99-or-later bool is the option that Gnulib has taken. Its 
>> 'stdbool' module and its gl_C_BOOL macro assumes C99 or later, and as 
>> far as I know no Gnulib-using package is using Gnulib's 'stdbool-c99' 
>> module which we kept around in case somebody still needed bool to work 
>> atop a C89 system. (We considered supporting C23 bool atop C89 but it 
>> was too painful.)
>
> I am fine with this option.

On the whole I’m also fine with this, but I think we need to consider,
separately, two kinds of Autoconf-using packages and three kinds of
compilers.

I think it’s definitely fine if Autoconf-using packages that request
support for ‘bool’, using either AC_C_BOOL or gl_C_BOOL, start requiring
a C99 compiler as of 2.72 (but see below).  I suspect there are existing
packages (Kermit comes to mind) that intend to maintain compatibility
with C89 compilers *forever*, and will choose *not* to use AC_C_BOOL,
and will be annoyed if AC_PROG_CC by itself starts rejecting C89 compilers.

(We may eventually decide we don’t support C89 compilers *at all*
anymore but that should be an independent discussion and not driven by
‘bool’.)

Then, on the compiler side of things, there’s compilers that have
complete support for ‘bool’ as it was specified in C99 (i.e. both the
‘_Bool’ keyword is recognized and a useful ‘stdbool.h’); there’s
compilers that have ‘_Bool’ but *don’t* have a useful ‘stdbool.h’; and
there’s compilers that don’t have any “true Boolean type” (as I put it
in the manual) at all.  In earlier discussions, IIRC, we determined that
compilers in all three of these categories do exist.

I suggest that what we mean by “Packages that use AC_C_BOOL require a
C99 compiler” is precisely “When @code{AC_C_BOOL} is used,
@command{configure} will error out if the C compiler does not recognize
either @samp{bool var;} or @samp{_Bool var;} as a valid complete
translation unit.”  In other words, the third category of compilers, the
ones that don’t have any “true Boolean type” (whose name we know), are
rejected.  However, compilers in the second category (_Bool available,
stdbool.h either unavailable or does not work) will be accepted and
config.h will perform the #defines that stdbool.h ought to have
performed.

> I just checked and both GCC 12.2 and clang 14 support <stdbool.h> in C89
> mode.  I do get a -Wc99-extensions warning from clang but that can easily
> be suppressed with -Wno-c99-extensions.

Good to know, thanks.

zw



reply via email to

[Prev in Thread] Current Thread [Next in Thread]