11 Sep
2009
11 Sep
'09
3:44 a.m.
On Wed, Sep 9, 2009 at 11:22 AM, Stewart, Robert<Robert.Stewart@sig.com> 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 with. - 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 platforms/compilers/settings - some warnings really are useless, and more often than not should be ignored (with pragmas or globally) - once you get to 0, stay there :-) Tony