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

[Zack Weinberg <zack@owlfolio.org>]

Rich Felker <dalias@libc.org> writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> 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.
…
> 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.

Right.  In principle, I think AC_CHECK_FUNCS([symbol]), where ‘symbol’ is
in either ISO C or in XSI, could be made to do a check of the form you
suggest at the end of https://ewontfix.com/13/

    #include <stdlib.h>
    #include <locale.h>
    int main()
    {
        double (*p)(const char *, char **, locale_t) = strtod_l;
    }

It’s “just” a matter of compiling that big list of headers and expected
function signatures.  I’d also want to do something to ensure that this
assignment is not optimized out, so the linker has to process an
undefined reference to the symbol.

For symbols that are not covered by the built-in list, we could require
people to indicate the necessary headers and signature somehow.
Hypothetical notation

    AC_CHECK_FUNCS([
        [argp_parse, [argp.h],
           [error_t], [const struct argp *, int, char **,
                       unsigned int, int *, void *]]
    ])

Note that this still isn’t perfect; if some system provides a function
with an identical type signature, but different *semantics*, to the one
the application wants, no compilation test can detect that.  Autoconf’s
not going to step away from its “avoid compile-and-run tests, that
breaks cross compilation” stance.

> 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

I vaguely recall some cases where this bit glibc and Apple’s libc as
well.

In principle, you’re supposed to be able to declare some ISO C functions
yourself, e.g.

    extern int printf(const char *, ...);
    int main(void) {
        printf("hello world\n");
    }

is strictly conforming per C99, but this bypasses any symbol renaming
applied by stdio.h.

> What I'd like to see happen is complete deprecation of the autoconf
> link-only tests

Do you have a concrete list of documented Autoconf macros that you would
like to see deprecated for this reason?

zw