On Tue, Dec 18, 2012 at 12:28 AM, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote: > Jim Meyering said: >> Did you realize that several GNU projects now enable virtually >> every gcc warning that is available (even including those that >> are new in the upcoming gcc-4.8, for folks that use bleeding edge gcc) >> via gnulib's manywarnings.m4 configure-time tests? >> >> Of course, there is a list of warnings that we do disable, >> due to their typical lack of utility and the invasiveness >> of changes required do suppress them. > > Is there any way that the autoconf (or automake) folks could make compiler warnings much, much easier to enable? Preferably enabled by default when you start packaging something? For example, could gnulib warnings and manywarnings be distributed and enabled as *part* of autoconf? If not, could autoconf at least strongly advertize the existence of these, and include specific instructions to people on how to quickly install it? The autoconf section on "gnulib" never even *MENTIONS* the "warnings" and "manywarnings" stuff! And while automake has warnings, they are for the automake configuration file... not for compilation. > > Compiler warning flags cost nearly nothing to turn on when you're *starting* a project, but they're harder to enable later (a thousand warnings about the same thing later is harder than fixing it the first time). And while some warnings are nonsense, their use can make the resulting software much, much better. If we got people to turn on warning flags all over the place, during development, a lot of bugs would simply disappear. > If you are going to try the waters with warnings, you should also consider the flags to integrate with platform security. Platform security integration includes fortified sources and stack protectors. Here are the flags of interest: * -fstack-protector-all * -z,noexecstack * -z,noexecheap (or other measure, such as W^X) * -z,relro * -z,now * -fPIE and -pie for executables FORTIFY_SOURCE=2 (FORTIFY_SOURCE=1 on Android 4.1+), where available. I know Drepper objects to the safer string/memory functions, but his way (the way of 1970's strcpy and strcat) simply does not work. I don't disagree that the safer functions are not completely safe, but I refuse to throw the baby out with the bath water. These measures would have stopped a number of recent high profile 0-days and security vulnerabilities, including those against MySQL (http://seclists.org/bugtraq/2012/Dec/12 and http://seclists.org/bugtraq/2012/Dec/11) and Pidigin (http://seclists.org/fulldisclosure/2012/Jul/183). For those who think its over the top, then let them shoot themselves in the foot by backing off security integration. Consider: Drepper is an expert, and even his loader and runtime library make appearances on Bugtraq and Full Disclosure. Mere mortals (like me and many other developers) need the integration to help build a secure system. A hardened or secure toolchain should be a part of every developer's warchest. It starts with the tools like Autoconf. Jeff _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
