Bob Friesenhahn <bfrie...@simple.dallas.tx.us>: > 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. Bob Friesenhahn <bfrie...@simple.dallas.tx.us>: > 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. Paul Eggert: > 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 _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
