On Mon, 14 Nov 2022 at 18:15, Paul Eggert <eggert@xxxxxxxxxxx> wrote: > > On 2022-11-14 04:41, Aaron Ballman wrote: > > it's generally a problem when autoconf relies on invalid > > language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And Clang therefore must be > careful about how it diagnoses invalid constructs. Clang shouldn't > willy-nilly change the way it reports invalid constructs, as that can > break Autoconf. There's a difference between checking whether an invalid construct works, where that construct is the subject of the test, and incidentally relying on invalid language constructs as part of testing for other things. > > issues of security > > like statically known instances of UB > > It's fine to report those; I'm not saying don't report them. All I'm > saying is that Clang should be careful about *how* it reports them. 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? What kind of changes to error reporting are you saying to be careful with? If Clang starts to diagnose a given provable-UB case (or any other construct) as an error instead of a warning, then it seems entirely correct for autoconf to report that the case does not work. That's the desired behaviour, isn't it? What we don't want is for autoconf to start reporting that *other* things don't work, as a result of autoconf relying on UB or ill-formed code when trying to check other things like the presence of function 'foo'. And that's why autoconf should avoid using invalid/undefined code when possible. > > At the very least if there are going to be changes in this area, the > Clang developers should notify Autoconf (and presumably other) > downstream users of the changes, and provide a supported way to get the > old behavior for reporting, and give downstream time to adapt.
