How can Autoconf help with the transition to stricter compilation defaults?
Paul Eggert via cfe-commits
cfe-commits at lists.llvm.org
Mon Nov 14 10:14:07 PST 2022
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.
> 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.
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.
More information about the cfe-commits
mailing list