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 http://sqlite.org/testing.html#coverage
>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk