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.
