From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 578061F910 for ; Sat, 12 Nov 2022 15:07:34 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=owlfolio.org header.i=@owlfolio.org header.b="KFp48ceI"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="HMBTE8uV"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ots6Q-0000Xk-O0; Sat, 12 Nov 2022 10:07:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ots6O-0000X0-Jc; Sat, 12 Nov 2022 10:07:24 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ots6M-0002gW-3M; Sat, 12 Nov 2022 10:07:24 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ABA215C009D; Sat, 12 Nov 2022 10:07:19 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 12 Nov 2022 10:07:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1668265639; x= 1668352039; bh=W8JjlBRjKY2RD2Qj5+9FtlWASWUiGAGiGyR5bE6A/84=; b=K Fp48ceIsco8Iw/dy/aWGUpBTDYk3tI4MbzHCjfya0cyQalGjhOaJT47Cfkcdgnv6 vREP9DInuvhkqscB5z/DExj9kenhbsy5wIlilhX7fc+ULeXzJZIJnITDIda4Kf9u UnMMFhHhxW5bEQF+4PSMR/+L66OUqjpiAviX83OR6uS6V/8tgK+tqWF1qWsSEhPO ht3XOHB0+V2dpunHhJu1cg+hrd9ZCcF/Q1bfbjDHqCSXrPz4xGKdbtiD2XfODty8 kYy6T72vDSfCDmHNP8i2rVQ4pq687wd6ay06yo2QRDRa0VoV50X9OullWwq2YqcO XLr/auL7E3X5fWZHHCDJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668265639; x= 1668352039; bh=W8JjlBRjKY2RD2Qj5+9FtlWASWUiGAGiGyR5bE6A/84=; b=H MBTE8uVV0LEZQ7JUdc627IArgqxdVetqJ8nErn0Gf6brU4W+2dunUIcnoksXMDp0 e0eWMHIVD3z+RNLWm7XYWZ2lWsspSNqK/9ISYu/QIsL3iXF27BuHDLrNvrTgb++N z2o//G22wh7WiWVxIxHtH0MKnFsfv5Z3oQWi8iZr47gtd62PoxnOzut+TXbGrNej /K7RTdCs1jH8GKYetOZGCmFDMRpGyBDtKPYoAU/Db7k/LRDfMGo3niX/E1yC8O4+ uXrm8BLLaSmjl6oKiYrqEEGQyodYLRO0g6btiyJLeLHDb1HwWLNdb3vntYo1Fvxa dFd3iW/vEcroLvLgaXtWw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeekgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufhffjgfkfgggtgfgsehtqh ertddtreejnecuhfhrohhmpegkrggtkhcuhggvihhnsggvrhhguceoiigrtghksehofihl fhholhhiohdrohhrgheqnecuggftrfgrthhtvghrnhephfdvveeugfejueehgeefjeehhf ehgeekjefhjefhgfevudfhheejgffgleffgfehnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Nov 2022 10:07:19 -0500 (EST) From: Zack Weinberg To: autoconf@gnu.org, bug-gnulib@gnu.org Cc: Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <0e07ba76-89be-2fa3-6ae3-88958d749cfe@cs.ucla.edu> <0b23f209-8c0e-efd3-cc2a-a1aa3808e797@gmail.com> Date: Sat, 12 Nov 2022 10:06:01 -0500 In-Reply-To: <0b23f209-8c0e-efd3-cc2a-a1aa3808e797@gmail.com> (Demi Marie Obenour's message of "Fri, 11 Nov 2022 21:42:06 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=66.111.4.25; envelope-from=zack@owlfolio.org; helo=out1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Demi Marie Obenour writes: > On 11/10/22 15:19, Paul Eggert wrote: >> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf= =20 >> supported K&R C, C89, C99, etc. At some point (I'm not sure when),=20 >> Autoconf started requiring C89 or later. Is it now OK for Autoconf to=20 >> require C99 or later, as far as bool is concerned? If so, that'll=20 >> considerably simplify the ongoing maintenance hassle for bool. >> >> Requiring C99-or-later bool is the option that Gnulib has taken. Its=20 >> 'stdbool' module and its gl_C_BOOL macro assumes C99 or later, and as=20 >> far as I know no Gnulib-using package is using Gnulib's 'stdbool-c99'=20 >> module which we kept around in case somebody still needed bool to work=20 >> atop a C89 system. (We considered supporting C23 bool atop C89 but it=20 >> was too painful.) > > I am fine with this option. On the whole I=E2=80=99m also fine with this, but I think we need to consid= er, separately, two kinds of Autoconf-using packages and three kinds of compilers. I think it=E2=80=99s definitely fine if Autoconf-using packages that request support for =E2=80=98bool=E2=80=99, using either AC_C_BOOL or gl_C_BOOL, st= art 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=E2=80=99t support C89 compilers *at all* anymore but that should be an independent discussion and not driven by =E2=80=98bool=E2=80=99.) Then, on the compiler side of things, there=E2=80=99s compilers that have complete support for =E2=80=98bool=E2=80=99 as it was specified in C99 (i.e= . both the =E2=80=98_Bool=E2=80=99 keyword is recognized and a useful =E2=80=98stdbool= .h=E2=80=99); there=E2=80=99s compilers that have =E2=80=98_Bool=E2=80=99 but *don=E2=80=99t* have a usef= ul =E2=80=98stdbool.h=E2=80=99; and there=E2=80=99s compilers that don=E2=80=99t have any =E2=80=9Ctrue Boolean= type=E2=80=9D (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 =E2=80=9CPackages that use AC_C_BOOL require= a C99 compiler=E2=80=9D is precisely =E2=80=9CWhen @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.=E2=80=9D In other words, the third category of compilers= , the ones that don=E2=80=99t have any =E2=80=9Ctrue Boolean type=E2=80=9D (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 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