[Top][All Lists]

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

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

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:


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]