Boost logo

Boost :

Subject: Re: [boost] Are warnings acceptable artifacts from builds?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-09-10 23:44:34

On Wed, Sep 9, 2009 at 11:22 AM, Stewart, Robert<Robert.Stewart_at_[hidden]> wrote:
> Vinnie wrote:
>> >From
>> We cannot call to mind a single problem in SQLite that was
>> detected by static analysis that was not first seen by one of
>> the other testing methods described above. On the other hand,
>> we have on occasion introduced new bugs in our efforts to get
>> SQLite to compile without warnings.
> My experience has been quite the contrary.  Chasing down compiler warnings has eliminated a good number of bugs in shared code here.  Sure, some of the bugs could have been found with better testing, but we have what we have.  Using a belt and suspenders is often helpful!
> Even for the SQLite team, eliminating all warnings makes new ones more promiment such that a developer is quickly alerted to what might be an issue before the code is checked in or undergoes testing.

We had a large code-base at Adobe that went through some warning
removal nightmares. Definitely caused more bugs than it fixed.
But once you get to 0, it makes new warnings easier to handle - and
these new warnings will lead to bug fixes. Seems contradictory, but it
is because new warnings are fixed with the code (and intentions) fresh
in your mind; old warnings are fixed by guesses from non-original
coders, who just want the warning to go away.

>From my experience
- be careful who fixes the warnings and how they do it - it is easy to
screw up, particularly if it is code they are not completely familiar
- having a large # of warning (1000's) makes it almost impossible to
take the right amount of care to get that number down
- you can quickly go from 0 to 1000 warnings by changing
- some warnings really are useless, and more often than not should be
ignored (with pragmas or globally)
- once you get to 0, stay there :-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at