On Tue, Nov 15, 2022 at 2:08 PM Paul Eggert <eggert@xxxxxxxxxxx> wrote: > > On 2022-11-15 06:50, Jonathan Wakely wrote: > > Could you clarify what you mean, with a concrete example? Surely as > > long as errors are reported on stderr and the compiler exits with > > non-zero status, that's an acceptable way to report errors? > > Not if the "error" is harmless as far as Autoconf is concerned, which is > what led to this thread. The concrete example here is that Autoconf > needs to check whether a function can be linked to (as opposed to > checking the function's signature). Clang shouldn't get in the way. What is harmless to autoconf is a critical flaw in another context. > In lots of places the C standard says behavior is undefined, even though > the behavior is fine on the current platform for the intended use. It's > not just the example we're talking about; adding zero to a null pointer > is another such example. > > In such cases it's OK for Clang to warn, but having Clang exit with > nonzero status is overkill and counterproductive. I don't know that this is particularly persuasive -- it effectively boils down to another variant of "I want to rely on a specific behavior for something that is UB". I don't think Clang can promise that we're not going to turn more statically-known UB into errors. ~Aaron
