public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Zack Weinberg <zack@owlfolio.org>,
	c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org,
	cfe-commits@lists.llvm.org, Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Thu, 10 Nov 2022 12:19:23 -0800	[thread overview]
Message-ID: <0e07ba76-89be-2fa3-6ae3-88958d749cfe@cs.ucla.edu> (raw)
In-Reply-To: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com>

On 2022-11-10 09:16, Zack Weinberg wrote:
> Changes to handle C23 built-in ‘bool’ better are under development but
> the design has not yet been finalized.

[I'm cc'ing this to bug-gnulib too.]

To my mind this is the biggest outstanding issue in Autoconf as far as 
C23 goes, as the upgrade path for Autoconf's existing bool support is 
not entirely clear. As Florian mentioned, distros can't assume Autoconf 
upgrades when building other packages; that being said, we should get 
Autoconf's bool support fixed sooner rather than later as bool hassles 
will remain until Autoconf is fixed and these fixes are propagated to 
Autoconf's users.

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.)

If we follow Gnulib's lead, Autoconf will generate a config.h that does 
"#include <stdbool.h>" on pre-C23 systems, and this config.h will not 
not work on pre-C99 systems. This of course could in theory break some 
programs, just as compiling them with C23 can break them. But I don't 
see any better option at this point. And besides, what package outside 
of a museum still requires C89 and don't work with C99?


  parent reply	other threads:[~2022-11-10 20:19 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 17:16 Zack Weinberg
2022-11-10 17:52 ` Nick Bowler
2022-11-10 17:58   ` Jonathan Wakely
2022-11-10 18:12     ` Jonathan Wakely
2022-11-10 18:44       ` Aaron Ballman
2022-11-12  2:56   ` Zack Weinberg
2022-11-10 18:05 ` Rich Felker
2022-11-10 21:44   ` Florian Weimer
2022-11-12  3:22   ` Zack Weinberg
2022-11-10 18:08 ` Florian Weimer
2022-11-12  3:40   ` Zack Weinberg
2022-11-12  3:43     ` Sam James
2022-11-12 14:27       ` Zack Weinberg
2022-11-12  3:45     ` Joseph Myers
2022-11-12 15:59   ` Wookey
2022-11-12 16:12     ` Zack Weinberg
2022-11-10 18:19 ` Aaron Ballman
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-10 20:19 ` Paul Eggert [this message]
     [not found] ` <d785b19371e8419f5a5817d7cdb429db91614a3a.camel@orlitzky.com>
2022-11-11  3:08   ` Sam James
2022-11-11  3:33     ` Zack Weinberg
2022-11-11  8:40       ` Sam James
2022-11-11  9:02       ` Paul Eggert
2022-11-12 14:09         ` Zack Weinberg
2022-11-11 23:25       ` Sam James
2022-11-12  0:53         ` Paul Eggert
2022-11-12  4:00           ` Sam James
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

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

  git send-email \
    --in-reply-to=0e07ba76-89be-2fa3-6ae3-88958d749cfe@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=autoconf@gnu.org \
    --cc=bug-gnulib@gnu.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=cfe-commits@lists.llvm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=zack@owlfolio.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).