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

[Alexander Monakov via cfe-commits]

On Wed, 16 Nov 2022, Michael Matz via Gcc wrote:

> I sympathize, and I would think a compiler emitting an error (not a 
> warning) in the situation at hand (in absence of -Werror) is overly 
> pedantic.  But, could autoconf perhaps avoid the problem?  AFAICS the 
> ac_fn_c_check_func really does only a link test to check for symbol 
> existence, and the perceived problem is that the call statement in main() 
> invokes UB.  So, let's avoid the call then while retaining the access to 
> the symbol?  Like:
> 
> -----
> char foobar(void);
> int main(void) {
>   return &foobar != 0;
> }
> -----
> 
> No call involved: no reason for compiler to complain.  The prototype decl 
> itself will still be "wrong", but compilers complaining about that (in 
> absence of a pre-existing different prototype, which is avoided by 
> autoconf) seem unlikely.
> 
> Obviously this program will also say "foobar exists" if it's a data 
> symbol, but that's the same with the variant using the call on most 
> platforms (after all it's not run).
> 
> The idea is so obvious that I'm probably missing something, why autoconf 
> can't use that idiom instead.  But perhaps the (historic?) reasons why it 
> couldn't be used are gone now?

Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
and thus no symbol reference remains in the resulting assembly.

Alexander