Re: [boost] Are warnings acceptable artifacts from builds?

Subject: Re: [boost] Are warnings acceptable artifacts from builds?
From: Sohail Somani (sohail_at_[hidden])
Date: 2009-09-14 10:51:24

On 09/09/09 8:54 AM, Vinnie wrote:
>> From http://sqlite.org/testing.html#coverage
>
> "Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however.
>
> Static analysis has not proven to be helpful in finding bugs. 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.
>
> Our experience, then, is that static analysis is counter-productive to quality. In other words, focusing on static analysis (being concerned with compiler warnings) actually reduces the quality of the code. Nevertheless, we developers have capitulated to pressure from users and actively work to eliminate compiler warnings. We are willing to do this because the other tests described above do an excellent job of finding the bugs that are often introduced when removing compiler warnings, so that product quality is probably not decreased as a result."

The SQLite developers are pretty good so I'm not saying that they are 
wrong. But...

Just because they had problems doing something does not mean it should 
not be done.

I enable warnings as errors in all my projects but for cross-platform 
code, it is really difficult to get right especially when a 
compiler/platform is added much later. Most of the time it ends up being 
stuff like "loss of data due to conversion" if we assign a size_t to an 
int so it helps to look at the line of code and make sure that it is safe.

After all, every bug found later costs more money.

-- 
Sohail Somani
http://uint32t.blogspot.com