Autoconf Digest, Vol 104, Issue 14

[David A. Wheeler]

It is pretty common that the person trying to eliminate a warning does
not understand the code well enough to understand the consequences of
their action or is interested in a quick fix.

But one reason this happens is that the original developer never saw the warning. If warnings are *on* by default, the original developer is far more likely to see and respond to them. Nowadays, developers pull from some repo and use autoconf to set up a working version. If the defaults don't turn on warnings, nothing else will either.

I understand your concern and the reasoning, but these sort of options
are highly platform/target/distribution specific. It is easy to
create packages which fail to build on many systems. Later, the baked
in settings of somewhat dated distribution tarballs may not meet
current standards.
Surely it is better to leave this to OS distribution maintainers who
establish common rules for OS packages and ensure that options are
applied in a uniform and consistent manner.

The whole *point* of autoconf is to make it easy to distribute packages that work on various systems. We have many, many examples where the "OS distribution maintainers" don't use what's available. Perhaps even more importantly, "Joe User" who installs software from source code will *NOT* know how to enable them, unless they happen to be in the site or system-wide config files. But since these capabilities aren't baked into autoconf, they are unlikely to be in the system-wide config files either.

Abstractly, I think Autoconf machinery to support security
checking is a good idea, but the devil is in the details.

Amen to that, of course :-).

--- David A. Wheeler