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

[Zack Weinberg via cfe-commits]

On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it 
> might be justifiable for default Clang to break Autoconf. But so far we 
> haven't seen real-world uses that would justify this pickiness for 
> Autoconf's use of 'char memset_explicit(void);'.

I don't have time this week to really get into this argument but I want to point out that I'm generally in agreement with Rich Felker's argument (in https://ewontfix.com/13/) that AC_CHECK_FUNC *should not* just probe for linkability of a symbol, because:

 - Not including the appropriate headers means that the probe bypasses compile-time symbol renaming and therefore probes for *the wrong symbol*, potentially causing both false detection and false non-detection (to tie it to another subthread, notice that one of the things -D_TIME_BITS=64 triggers (from glibc's headers) is enable dozens of __REDIRECT annotations in time.h)

 - Only probing the symbol, and not its type signature, means for instance that if the program expects GNU strerror_r but the system provides POSIX strerror_r, or vice versa, Autoconf's check will succeed but the program will fail to compile (in more subtle cases it might be miscompiled instead)

(N.B. I *don't* agree with the assertion at the bottom of that page that "taking explicit action to prevent linking against [symbols intended to be exposed for binary compatibility only], involves hacks that are even worse and more fragile than what configure is doing" -- yes, it sucks that the toolchain support for ELF symbol versioning is still mostly absent, 20 years after the concept was introduced, but `asm(".symver __strtod_l_compat, strtod_l at SOME_CONCRETE_VERSION_TAG")` is straightforward (if cryptic) and robust on all the platforms where it works at all.)

zw