|
From: | Paul Eggert |
Subject: | Re: How can Autoconf help with the transition to stricter compilation defaults? |
Date: | Thu, 17 Nov 2022 10:45:53 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
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.htmlwhich 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.
[Prev in Thread] | Current Thread | [Next in Thread] |