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

[Florian Weimer via cfe-commits]

* Zack Weinberg via Gcc:

> 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.

Thank you for reaching out.  The c-std-porting list isn't even
bootstrapped yet, the Fedora documentation is still in flux, and the
Fedora oversight body just approved working on this in the Fedora
context.  That LWN article caught me a bit off guard.

Anyway, 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.

> 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>).

Thanks, these changes are going to be helpful to get a clean run from
our Fedora tester.

I also noticed some issues in the automake test suite, and I hope
Frederic can have a look at them:

  automake: Port to modern C
  <https://bugzilla.redhat.com/show_bug.cgi?id=2137515>

> 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>.

One reason I hesitate to recommend wide testing with -Werror=… is that
it is actually impossible to model future GCC behavior with -Werror=…
options today.  I very much doubt that the AC_CHECK_FUNC change [that
is, () → (void)] will ever be required by real GCC.  I'm worried that
some of this -Werror=… testing merely introduces unnecessary churn.
These changes help maintainers who wnat to build their packages with
CC="gcc -Werror=…" or something like that, so I guess they still make
sense for autoconf.  But perhaps not as a general model for everyone
else.

> 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'.

I think t his approach is actually the most portable approach, at least
as far as GCC is concerned.  GCC treats a function as a compiler
built-in only if the declared prototype matches its expectations.  I
doubt there are any such functions returning char, which makes this
declaration a good choice.  I do not expect any medium-term changes to
the situation here.  The warning will stay, it will not turn into an
error.

> 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.

Once you include the header, you also need to know function parameters,
otherwise you won't be able to form a valid call.  Python
setuptools/distutils tried to do something along this lines, but I can't
see how it can work, as explained here:

  Unclear how CCompiler.has_function works for functions with parameters
  <https://github.com/pypa/setuptools/issues/3648>

The char-returning prototype does not seem so bad in the end.  The
function is actually called and the result returned from main, so it's
even compatible with LTO.

> How important do you think it is for this to be fixed?

In isolation?  Not important at all.  Maybe it would make sense to fix
this as part of some other feature, like bulk probing for function
support, with multiple functions in one compiler/linker invocation.
That is, enhance the toolchain to support more efficient execution of
autoconf scripts and their probes.

> Are there any other changes you would like to see in a near-future
> Autoconf 2.72 in order to make this transition easier?

I appreciate the thought, but as I said initially: the bulk of the
problem is with software which we cannot simply autoreconf, so changes
in future autoconf behavior are of limited help unfortunately.

Even if we can autoreconf, there are popular aclocal.m4/autoconf-archive
fragments that get copied around.  For example, there is a stack
direction test that I not-quite-fixed in libiberty that exist in various
forms in many projects:

  <https://codesearch.debian.net/search?q=find_stack_direction&literal=1>

I said not-quited fixed because even though I fixed the C99
compatibility issues in libiberty, the test still gives the wrong result
on x86-64 because it compares the address of independent objects from
different stack frames, which gives indeterminate results with
optimization GCC.  But fortunately, the stack direction test is only
used for implementing alloca emulation, and we don't need that when
building with GCC.  (Curiously, many of the non-GCC
find_statck_direction variants have already been fixed for C99
compatibility.)

Probably the most challenging aspect of all this is to avoid getting
sucked into these little side quests.

> p.s. GCC and Clang folks: As long as you’re changing the defaults 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.

> can you please also remove the last few predefined
> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
> -std=gnuXX 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.

Thanks,
Florian