From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id 814463858C29 for ; Sat, 12 Nov 2022 03:41:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 814463858C29 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.nyi.internal (Postfix) with ESMTP id 4D8AD5C0086; Fri, 11 Nov 2022 22:41:40 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 11 Nov 2022 22:41:40 -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=1668224500; x= 1668310900; bh=EjfFrlMdZGCIRkn9rOUhIvLcmz3vFKG9PWJpFlkmLyY=; b=e M1soiEAe1PK7hlT0eQYhvSwEVFvhrnkBswBndIAth2OBiaSjKxWf9u7MHNoX2US8 xXTImZHoyZxpfov3cleK3ETK9loxtWtLuKAmtAqC0dYfh2qwljK9MZl8fPgDQvj6 zhSRL74FIs/EQMWwCQGNNRDrMlVK+9ogX1GMZqyUwdb4gj+ivG5bukvKRRZwPddu avKWEyn7Cta6TUZVw2ChmbKaaDJdGi1S6O2l/wjAHFedbwTLW/1nL78e8T5iK735 uEu61FR+zr3zDE1bWWn0wnXrwlBK4Wc6jGBFAwpkm9NpLPjqyUNKB5LCaussIiYb 2uglafYjFyEcW9ZDCNC7Q== 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=1668224500; x= 1668310900; bh=EjfFrlMdZGCIRkn9rOUhIvLcmz3vFKG9PWJpFlkmLyY=; b=p MVcFJNrCiggktuuyZ9/cAVVydNzl7f/HKlit42z7o5DAqUVfgiXGB9PQ+ei9Focp IkpRWou0chPBbdN7BIwu5aOasaRhuvaWVFOyjc97ML8LaH0UTjBVhP9ZhcYNLXO3 +RfhaBzRZUQM9/UVl6Ezr+riIOIwGvesD8ubSJjQ3ga6haAo1o5ljYp72v4jAGBX 1NYi7emiMIQWE7SwGI6ETpv9bVJzdIiWTmHDUJKlWRuudRH3Gzl0+wGuRgmw+7TV cW+jqYovmQJ9zFzOwmlwx6i6frdmv0cmD5HjCol8tKuU4JVltGi3XD559mvzw+oJ vmIG18ZVpCcY1fRqCEh1A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeejgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufhfffgjkfgfgggtgfesthhqredttderjeenucfhrhhomhepkggrtghk ucghvghinhgsvghrghcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtffrrg htthgvrhhnpefhvdevuefgjeeuheegfeejhefhheegkeejhfejhffgveduhfehjefggfel fffgheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe iirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Nov 2022 22:41:39 -0500 (EST) From: Zack Weinberg To: Florian Weimer Cc: Zack Weinberg via Gcc , c-std-porting@lists.linux.dev, autoconf@gnu.org, cfe-commits@lists.llvm.org, Frederic Berat Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <87v8nmsmwt.fsf@oldenburg.str.redhat.com> Date: Fri, 11 Nov 2022 22:40:21 -0500 In-Reply-To: <87v8nmsmwt.fsf@oldenburg.str.redhat.com> (Florian Weimer's message of "Thu, 10 Nov 2022 19:08:02 +0100") 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 X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Florian Weimer writes: > based on a limited attempt to get this fixed about three years > ago, I expect that many of the problematic packages have not had their > configure scripts regenerated using autoconf for a decade or more. This > means that as an autoconf maintainer, you unfortunately won't be able to > help us much. I=E2=80=99m sadly not surprised. This is definitely more work than I can see myself doing on a volunteer basis, but a 2.69.1 patch release =E2=80=94 nothing that=E2=80=99s not alre= ady on trunk, cherry pick the changes needed to support the newer compilers (and also newer Perl and Bash and M4) is a thing that could happen. > Thanks, these changes are going to be helpful to get a clean run from > our Fedora tester. Autoconf=E2=80=99s own test suite is sadly not very thorough. If you find = more problems I will prioritize them. > Once you include the header, you also need to know function parameters, > otherwise you won't be able to form a valid call. You can assign to a function pointer variable if you know the complete type signature, which is desirable for other reasons (see reply to Rich). Needing to know how to form argument *values* could be much more trouble, but I don=E2=80=99t think it should be necessary. >> p.s. GCC and Clang folks: As long as you=E2=80=99re changing the default= s out >> from under people, > > Hmph, I wouldn't frame it this way. We are aware of GCC's special role > as the system compiler. We're trying to upstream the changes to sources > before flipping the compiler default. (The burden of being a system > compiler and all that.) A 25-year transition period evidently wasn't > enough, so some effort is still needed. We may conclude that removing > these extensions is too costly even in 2024. I didn=E2=80=99t mean to imply that I disliked any of the changes. In fact, with my day job (CS professor) hat on, I am quite looking forward to not having to warn the kids about these legacy features anymore (we don=E2=80= =99t _teach_ them, but they inevitably use them by accident, particularly implicit function declarations, and then get confused because =E2=80=98cc= =E2=80=99 with no -W options doesn=E2=80=99t catch the mistake). >> can you please also remove the last few predefined >> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the >> -std=3DgnuXX modes? > > That's a good point, I'll think about how we can instrument GCC to > support tracking that. We won't be able help with -Darm on the Fedora > side (the AArch64 port doesn't have that, and there's no longer a Fedora > 32-bit Arm port), but -Dlinux and -Dunix we can help with. These are also a trip hazard for novices, and the only way to turn them off is with -std=3DcXX, which also turns another trip hazard (trigraphs) *on*=E2=80=A6 so yeah, anything you can do to help speed up their removal, I think it=E2=80=99d be worthwhile. zw