[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enabling compiler warning flags

From: Jeffrey Walton
Subject: Re: Enabling compiler warning flags
Date: Thu, 20 Dec 2012 14:46:07 -0500

On Tue, Dec 18, 2012 at 12:28 AM, David A. Wheeler
<address@hidden> 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
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

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!

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]