Re: How can Autoconf help with the transition to stricter compilation defaults?

[Rich Felker]

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:
> <https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a75953b6d504f0405b1ca33b039b8dd39eef4>).
> 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,
> <https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016c7ed2d67f31b03a3d2e361858ff5299b>.
> 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