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

[Paul Eggert via cfe-commits]

On 2022-11-16 10:40, Jeffrey Walton wrote:
> This line of arguments is not persuasive. It is full of logical fallacies.

... none of which you stated.

No matter how we solve the problem, it will be a hack that exploits 
"logical fallacies" (whatever that means). However, a reaction "You 
violated the C standard! You deserve to be punished!" is not the best 
one for the overall software ecosystem. Lots of programs violate the C 
standard every day, and Clang supports them anyway.

Yesterday I dealt with this Autoconf bug report:

https://lists.gnu.org/r/autoconf/2022-11/msg00092.html

which basically said, "Here's some longstanding buggy code that uses 
Autoconf. This buggy code happened to work in the previous stable 
Autoconf version, but it stopped working in the bleeding-edge version."

Did I respond, "That's buggy code and it deserves to be punished?" No, I 
responded that it's buggy code that needs to be fixed (and gave a fix), 
but fixing this sort of thing is a hassle for distributors and so I also 
installed a minor hack to bleeding-edge Autoconf that lets the buggy 
code work again, at least for now. 
<https://lists.gnu.org/r/autoconf/2022-11/msg00118.html>

It would help if Clang developers could cooperate to address this 
potential problem with stricter compilation defaults. It's a real 
problem. And it shouldn't require much work on the Clang side to address it.