Re: [boost] Coverity Static Code Analysis

Subject: Re: [boost] Coverity Static Code Analysis
From: Gennaro Prota (gennaro.prota_at_[hidden])
Date: 2009-02-05 09:12:31

{I posted this yesterday; apparently it got lost}

John Maddock wrote:
>> Perhaps you shouldbt use or follow boost since it appears so fraught 
>> with ill design and poor quality. I personally have found it otherwise.
> 
>> I'm afraid that if I wanted to really reply to this I'd have to
>> question your professional skills. Significantly. Which I don't
>> want to do.
> 
> Guys, I'm not pointing any fingers, but please don't allow this to 
> degenerate into a flame war.

That's why I said "I don't want to".

> I'm sure there are many ways Boost can be improved, please focus on 
> specific issues, and one would hope their solutions

Which is the "patches are welcome", "if you notice anything
wrong you can fix it" attitude I mentioned earlier. Don't fool
yourself into believing that with enough time and contributions
all problems will eventually get fixed. It never happens. (If
nothing else: new stuff gets added much faster than existing
things fixed).

Believe me, I'm speaking in cognition of the facts: I'm not new
to Boost and its code, and I find issues with it (ranging from
minor to very sever ones, including undefined behavior) every
time I look at anything. No strive.

That's not very different from other free software. The
peculiarity, actually, is elsewhere: if anything can be
complicated, that's how Boost does it. If it can be
overgeneralized, that's what boost does (never used a function
with 15 arguments? doesn't matter... let's drag the whole pp-lib
in, so that the user can choose to have up to 8589934592 of
them). If it can be meta-programmed, or use conditional
compilation... you got it. So, I'd bet that in addition to the
obvious ones, a whole lot of very hard to spot issues lie in the
Boost code. Hoare comes to mind:

   There are two ways of constructing a software design: One way
   is to make it so simple that there are obviously no
   deficiencies, and the other way is to make it so complicated
   that there are no obvious deficiencies. [...]

Just to add a little example here, I grepped for the first thing
that occurred to me: "LocalFree". Because because I remembered
having seen many snippets of the kind

   <code which can throw an exception>
   ::LocalFree( p ) ;

(would Coverity find that?). Well, I immediately ended up in a
file named win32_api.hpp which has *a list of declarations of
Windows API functions*, conditioned on BOOST_USE_WINDOWS_H.
Terrific. A manner to have an undefined behavior, and condition
it on a "user preference", I had never thought of.

-- 
Genny