From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by sourceware.org (Postfix) with ESMTPS id 470B03858C60 for ; Thu, 10 Nov 2022 17:17:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 470B03858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2271E3200938; Thu, 10 Nov 2022 12:17:39 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Thu, 10 Nov 2022 12:17:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm3; t=1668100658; x=1668187058; bh=19nj7OjNQX X0XsQbNcxowqECm4Md46YhijYfaGR5y6M=; b=r3VJmM+5f/9wrZSaT6QDtRA9ro 5l8qm9yowcslJd65LFB5mF22KE58irwa/CuU2xXj5Jcp1FBewr5ymkWgXgMcFoAL sr5OVTzoBr24tuK7TiUgHtwRet3eYoPEHihLrcqhz0x6pefeVywIEYTKIvimDZl6 EMdHKoOEn7kT4YtGfKZgD/nCRSq9bA4eAAyWH5A3lIANUUdf5I3bG/5ZxSfYNUFQ n0WvHWa17r5jz17qcrfZpdtspZPlXbjMZeSmcQMewGH7AF2jfI1SUQSQhPMQGiJ1 kpfcsrSAgpMAiAQPqQLwyyHOcD0r+27wyrrV9cspv/KKC/OksNKNU3+poHSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version: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=1668100658; x=1668187058; bh=19nj7OjNQXX0XsQbNcxowqECm4Md 46YhijYfaGR5y6M=; b=kBxyPaGsrnaqhq2Epu0fto+79XTeeBUOMGbCb6oALqnZ VyZlbqMA8EzBSUMeU7WTqUKxQUu5hU6RFOul0UchSb4zQUbn6W7BFh9h2c5UNptV 5ARpuHeKYTdb6tQ34XGfQWUoickiDNq2q3Ro0+xlw3MTSwhcn5kuGGkuteou7SfF krY8Pz2DCqcifXe907W64i48uYDnm0fihemzQl3DAJwJA5vNAgBwF8J9mkE8xF1+ T6CTAXbNhw2LirKxyND+ZD0ndA+I/IkADSh7G2SlO3bWEyuZPcq4A/Tmmm76VI2p e3goutarY28nqnNaZ4rKjwu7ikp4PzkUZcdzCqd4Vg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeeggddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdgkrggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohif lhhfohhlihhordhorhhgqeenucggtffrrghtthgvrhhnpefggffgvdfhledutdduudffhf eugfdvgeethfejvefhueduvddvieevgfefhfdthfenucffohhmrghinheplhifnhdrnhgv thdpfhgvughorhgrphhrohhjvggtthdrohhrghdpghhnuhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeiirggtkhesohiflhhfohhl ihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6E64A272007A; Thu, 10 Nov 2022 12:17:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> Date: Thu, 10 Nov 2022 12:16:20 -0500 From: "Zack Weinberg" To: c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org Subject: How can Autoconf help with the transition to stricter compilation defaults? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I=E2=80=99m the closest thing Autoconf has to a lead maintainer at prese= nt. It=E2=80=99s come to my attention (via https://lwn.net/Articles/913505/ = and https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and Clang both plan to disable several =E2=80=9Clegacy=E2=80=9D C language f= eatures by default in a near-future release (GCC 14, Clang 16) (see the Fedora wiki link for a list). I understand that this change potentially breaks a lot of old dusty code, and in particular that Autoconf-generated configure scripts use constructs that may *silently give the wrong answer to a probe* when a stricter compiler is in use. Nobody has a whole lot of time to work on Autoconf at present, but I would like to ask, anyway, what Autoconf could potentially do to make this transition easier. I=E2=80=99m already aware that the test code Au= toconf 2.71 uses to probe for C89/C99/C11 support is broken; this has been fixed in development trunk to the extent it is possible for me to test it with GCC 12 (commit: ). Several other places using K&R function definitions and/or unprototyped function declarations (including the ubiquitously used AC_CHECK_FUNC) have also been fixed on trunk, . Changes to handle C23 built-in =E2=80=98bool=E2=80=99 better are under d= evelopment but the design has not yet been finalized. The biggest remaining (potential) problem, that I=E2=80=99m aware of, is= that AC_CHECK_FUNC unconditionally declares the function we=E2=80=99re probin= g for as =E2=80=98char NAME (void)=E2=80=99, and asks the compiler to call it = with no arguments, regardless of what its prototype actually is. It is not clear to me whether this will still work with the planned changes to the compilers. Both GCC 12 and Clang 14 have on-by-default warnings triggered by =E2=80=98extern char memcpy(void);=E2=80=99 (or any other s= tandard library function whose prototype is coded into the compiler) and this already causes problems for people who run configure scripts with CC=3D'cc -Werror'. Unfortunately this is very hard to fix =E2=80=94 we = would have to build a comprehensive list of library functions into Autoconf, mapping each to either its documented prototype or to a header where it ought to be declared; in the latter case we would also have to make e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h sys/socket.h netdb.h]) which might mess up configure scripts that aren=E2=80=99t expecting headers to be probed at that point. How important do you think it is for this to be fixed? Are there any other changes you would like to see in a near-future Autoconf 2.72 in order to make this transition easier? zw p.s. GCC and Clang folks: As long as you=E2=80=99re changing the default= s out from under people, can you please also remove the last few predefined user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the -std=3DgnuXX modes?