On Sat, Nov 12, 2022 at 7:43 PM Paul Eggert <egg...@cs.ucla.edu> wrote: > > On 2022-11-11 07:11, Aaron Ballman wrote: > > We believe the runtime behavior is sufficiently dangerous to > > warrant a conservative view that any call to a function will be a call > > that gets executed at runtime, hence a definitive signature mismatch > > is something we feel comfortable diagnosing (in some form) by default. > > As long as these diagnostics by default do not cause the compiler to > exit with nonzero status, we should be OK with Autoconf-generated > 'configure' scripts. Although there will be problems with people who run > "./configure CFLAGS='-Werror'", that sort of usage has always been > problematic and unsupported by Autoconf, so we can simply continue to > tell people "don't do that".
That's good to know, but is a problem more generally -- we are strengthening more diagnostics to be warnings that are treated as an error by default. This gives our users the best experience in terms of diagnostic behavior -- they're clearly alerted to serious issues in their code (either issues of conformance, like with use of implicit int or implicit function decls in C99 or later, or issues of security like statically known instances of UB), but they still have the chance to downgrade the diagnostic back into a warning (good as a temporary solution to start migrating code) or disable the diagnostic entirely (good if you plan to never update your compiler version but otherwise not recommended). Some of these diagnostics are expected to change to be error-only diagnostics in the future, so this strengthening helps to set user expectations as well. That's why it's generally a problem when autoconf relies on invalid language constructs -- it creates a tension between the autoconf uses and improving the C ecosystem. The autoconf uses aren't always unreasonable, but are very much a special case scenario compared to general C development. I suspect that as the security posture of the C language and its implementations improves in response to recent concerns around suitability of the language (https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF), this tension will come up more frequently. ~Aaron
