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

[Zack Weinberg]

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@SOME_CONCRETE_VERSION_TAG")` is straightforward (if cryptic) and 
robust on all the platforms where it works at all.)

zw