On Tue, Dec 18, 2012 at 12:28 AM, David A. Wheeler <dwhee...@dwheeler.com> 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. > To further muddy the water, there are also preprocessor macros that affect security!
Debug configurations can/should have _DEBUG and DEBUG preprocessor macros; while Release configurations should/must have _NDEBUG and NDEBUG preprocessor macros. Posix only observes NDEBUG (http://pubs.opengroup.org/onlinepubs/009604499/basedefs/assert.h.html). The additional Debug and Release preprocessor macros help ensure the 'proper' or 'more complete' uptake of third party libraries (such as SQLite and SQLCipher). Other libraries also add additional macro dependencies. For example Objective C Release configurations also need NS_BLOCK_ASSERTIONS=1 defined. If a project does not observe proper preprocessor macros for a configuration, a project could fall victim to runtime assertions and actually DoS itself after the assert calls abort(). The ISC's DNS server comes to mind (confer: there are CVE's assigned for the errant behavior, and its happened more than once! http://www.google.com/#q=isc+dns+assert+dos). So there you have it: all the elements of a secure toolchain. It includes the preprocessor (macros), the compiler (warnings), and linker (platform security integration). Many people don't realize all the details that go into getting a project set up correctly, long before the first line of code is ever written. And it applies to Makefiles, Eclipse, Net Beans, Xcode, Visual Studio, et al. Its not just limited to one tool or one platform. Jeff _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
