From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 05EE63858D1E for ; Thu, 10 Nov 2022 18:05:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 05EE63858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Thu, 10 Nov 2022 13:05:01 -0500 From: Rich Felker To: Zack Weinberg Cc: c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? Message-ID: <20221110180458.GA7026@brightrain.aerifal.cx> References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote: > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s 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 “legacy” C language features 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’m already aware that the test code Autoconf > 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 ‘bool’ better are under development but > the design has not yet been finalized. > > The biggest remaining (potential) problem, that I’m aware of, is that > AC_CHECK_FUNC unconditionally declares the function we’re probing for > as ‘char NAME (void)’, 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 ‘extern char memcpy(void);’ (or any other standard > library function whose prototype is coded into the compiler) and this > already causes problems for people who run configure scripts with > CC='cc -Werror'. Unfortunately this is very hard to fix — 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’t 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? Thanks for bringing this up. It is very important and I am very much in favor of making these changes and doing it in a way that existing broken and unmaintained software can be made to work just by re-generating configure scripts with up-to-date autoconf, even if that means hard-coding a list of headers needed to get the right declarations and automatically pulling them in. Otherwise this is going to be a gigantic burden on distro maintainers/systems integrators. I've been writing/complaining about autoconf doing this wrong for decades, with the best writeup around 9 years ago at https://ewontfix.com/13/. Part of the reason is that this has bitten musl libc users over and over again due to configure finding symbols that were intended only as ABI-compat and trying to use them (without declarations) at the source level, leading to various messes, some of which we're only just extricating ourselves from now: https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4 https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc But aside from issues like this, just the fact that autoconf was precluding making -Werror=implicit-function-declaration default must have wasted tens if not hundreds of thousands of human hours debugging broken builds. What I'd like to see happen is complete deprecation of the autoconf link-only tests -- only keeping them for use by legacy unmaintained projects in the form where they actually implicitly include the right header and test compile and link using that. Rich