bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@owlfolio.org>
To: autoconf@gnu.org, bug-gnulib@gnu.org
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Sat, 12 Nov 2022 10:06:01 -0500	[thread overview]
Message-ID: <ypik35aociw6.fsf@owlfolio.org> (raw)
In-Reply-To: <0b23f209-8c0e-efd3-cc2a-a1aa3808e797@gmail.com> (Demi Marie Obenour's message of "Fri, 11 Nov 2022 21:42:06 -0500")


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


  parent reply	other threads:[~2022-11-12 15:07 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com>
2022-11-10 20:19 ` How can Autoconf help with the transition to stricter compilation defaults? Paul Eggert
     [not found]   ` <0b23f209-8c0e-efd3-cc2a-a1aa3808e797@gmail.com>
2022-11-12 15:06     ` Zack Weinberg [this message]
     [not found] ` <CAAt6xTt75qBzQKt7_0ZPGaOBGnbDsuM8j_owRYzjc21n7NMqDQ@mail.gmail.com>
2022-11-10 21:05   ` Paul Eggert
2022-11-11 15:11     ` Aaron Ballman
2022-11-13  0:43       ` Paul Eggert
2022-11-14 12:41         ` Aaron Ballman
2022-11-14 18:14           ` Paul Eggert
2022-11-14 18:30             ` Florian Weimer
2022-11-14 18:35             ` Aaron Ballman
2022-11-15 14:50             ` Jonathan Wakely
2022-11-15 19:08               ` Paul Eggert
2022-11-15 19:27                 ` Jonathan Wakely
2022-11-15 20:27                   ` Paul Eggert
2022-11-15 20:57                     ` Aaron Ballman
2022-11-15 23:09                       ` Paul Eggert
2022-11-15 23:43                         ` Ben Boeckel
2022-11-16 14:26                     ` Michael Matz
2022-11-16 14:40                       ` Alexander Monakov
2022-11-16 15:01                         ` Michael Matz
2022-11-16 15:27                           ` Richard Biener
2022-11-16 15:35                             ` Sam James
2022-11-16 15:59                               ` Michael Matz
2022-11-16 16:20                                 ` Jonathan Wakely
2022-11-16 16:34                                   ` Michael Matz
2022-11-16 16:46                                     ` Jonathan Wakely
2022-11-16 18:17                       ` Paul Eggert
2022-11-16 18:40                         ` Jeffrey Walton
2022-11-17 18:45                           ` Paul Eggert
2022-11-16 18:59                         ` Zack Weinberg
2022-11-17 18:58                           ` Paul Eggert
2022-11-17 21:35                             ` Bruno Haible
2022-11-17 22:27                               ` Paul Eggert
2022-11-17 13:30                         ` Michael Matz
2022-11-15 20:36                 ` Aaron Ballman
2022-11-15  5:03         ` Sam James
2022-11-15 13:30           ` Zack Weinberg
2022-11-15 13:34             ` Sam James
2022-11-16  0:08           ` Bob Friesenhahn
2022-11-13  0:43       ` Paul Eggert
2022-11-17 13:57         ` Jason Merrill
2022-11-11  9:15 ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ypik35aociw6.fsf@owlfolio.org \
    --to=zack@owlfolio.org \
    --cc=autoconf@gnu.org \
    --cc=bug-gnulib@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).