Re: Warnings in the C++ Front-End and GCC in General

[Joe Buck <jbuck at synopsys dot com>]

> On Tue, 8 Sep 1998, Joe Buck wrote:
> 
> > > What if you worked for a company that required, as part of their coding
> > > style, warningless compilation?
> > But if we provide pragmas to turn off warnings and you use them, you
> > are violating your company's coding style!
> 
> Not at all. The warning is not generated despite the strict compilation
> options, so I reach the goal: some nigtly running cron job that compiles
> the whole project and scans the output for diagnostics won't find any.

But if your company had a good reason for not wanting any warnings, then
you've cheated.  That is, if your company believes that code that doesn't
have any warnings is good and code that has warnings is bad, the code is
still bad if you've added pragmas to turn off the warnings.

(In practice your company should accept a small number of warnings
provided that there is an explanation, for each warning, why the warning
is not a problem).

> > (This is why -Wall should only contain warnings that can be silenced
> > without making code worse).
> 
> Clearly, this is not the case. Initializing a variable does make the code
> worse, and so does providing an unreachable "return 0;" statement. 

Right, this is because the flow analysis is not as good as it could be.
In practice, though, depending on coding style these aren't needed all
that often, or can be avoided without penalty by restructuring that may
even make the code more readable.

But I was really talking about "significantly worse".  For example, at
one point someone added a warning that would have forced people to double
the size of all "envelope" classes (for C++ designs that use the "envelope
and letter" pattern, where an outer class delegates methods to an inner
class) to get rid of a warning.  Clearly that would significantly degrade
code.  Adding a small amount of unreachable code, on the other hand, is
far less of a cost, especially if it is rarely needed.

> Granted, it's a minor difference, but it exists. More importantly, such
> code makes other people looking at the code wonder "Hmm, this is a dead
> code, maybe there's a bug somewhere here?". Sure, I can (and actually do)
> put comments like "to shut -Wall up", but that's just an awful patch on
> top of another patch.

What is currently dead code may not be dead code after three years of
maintainance.  That's why putting something there, at least a comment
and possibly an assert, is justified.  Writing the code the first time
is vastly less work than you and your colleagues will spend on the code
in its entire lifetime.

> > In such cases, rather than turning off warnings, a mechanism like the
> > old lint /*NOTREACHED*/ would be preferable.
> 
> What would be preferable in it, compared to pragmas or whatever else?

A pragma is going to be compiler-specific.  /*NOTREACHED*/ goes back to
the earliest days of Unix; people know what it means.  A tool could turn
it into an assert if desired.

Besides, some indication that a particular point in the flow cannot be
reached may turn off about six different warnings: unininitialized
variables, returning without a value, and several others.