That’s very unfortunate and I’m sorry for the trouble caused! Thank you for raising the issue.
[quote=“mgorny, post:1, topic:65213”]
While I wholeheartedly agree with working towards fixing these cases to use proper code, I don’t think making the warning an error by default is the right way to do so.[/quote]
Despite the breakage, I’m not certain I agree. At some point, distro maintainers need to allow implementations to recapture design space that has been an error for 20+ years and help to improve the ecosystem’s security posture. I’m very sympathetic to the lack of a deprecation period between C89 and C99 basically requiring implementations to give a lot of grace to older code bases, but at some point we need to bite the bullet and maintain these packages or drop them. 20 years is a LOT of grace period. Defaulting the warning to an error is basically the only way forward IMO because everyone who was going to react to a warning has already done so. (NB: we intend to eventually go to a hard error due to the security concerns which caused this feature to be removed from C99 in the first place, so kicking the can down the road isn’t going to help.)
If it forces people to maintain code that’s important to them, it’s also a win IMO. 
That said, we want to limit the disruption as much as we can.
This was already shipped in Clang 15, so the horses have left the barn (this was very much not a regression and so I don’t think it would be appropriate to change the behavior further in 15.0.x – that just makes the landscape even more confusing and difficult for users). However, if distros want to revert that change locally to build their packages, that’s perfectly reasonable. But it doesn’t solve the long-term problem, either.
I generally agree.
In terms of where we go from here, I see a few paths:
- We could attempt to work around the configure script nonsense by recognizing when the compiler is executed by a configure script and run in a special “we’re dealing with an extremely low quality configure script” mode (and or/providing a flag so users can force this mode). This would keep configure scripts working while not punishing the rest of the ecosystem. I have no idea how easy or hard it would be, but I believe GCC is doing something similar and so it seems at least plausible.
- We could downgrade back to a warning in Clang 16. I don’t think this is a good option. Not only do we end up with inconsistent behavior from release to release, it’s plain worse security posture to assume that the linker will magically make everything work, especially with today’s significantly more complicated linking landscape compared to what existed in 1989. Since we poked the bear with Clang 15, I think we should stay the course rather than retreat.
- Do nothing. This leaves distro maintainers in a tough spot (but perhaps no tougher than the spot we’ve already put them in) and makes it harder for folks to build ancient software packages themselves. This may push some folks away from using Clang. It may also start to cause some folks to maintain the unmaintained software, at least to keep it hobbling around.
Perhaps there are other ways forward as well? Personally, I think #1 would be ideal if someone has the ability to do that work, but that may be a big ask.
At least, for a temporary solution, distro maintainers can either build those old packages with Clang 14 or can back the diagnostic changes out of their local Clang 15 branch, so am I correct in understanding we don’t have to rush for a fix here?