Re: How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman <aaron@aaronballman.com>]

On Sat, Nov 12, 2022 at 7:43 PM Paul Eggert <eggert@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