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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux