Re: [boost] Coverity Static Code Analysis

Subject: Re: [boost] Coverity Static Code Analysis
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-05 11:41:07

Gennaro Prota wrote:
>> 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.

Things are not perfect, and Boost is no exception and noone said it is. 
And, I'm sure you know it, commercial software is no exception either. 
The only thing you can do about it is to make it better. Spreading 
depression won't make you any good. So, being a bit more constructive, 
IMO, is the right thing to be busy with. If you have a specific problem 
in mind, go ahead and create a Trac ticket. And yes, "patches are 
welcome", really.

> 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. [...]

Boost comprises generic solutions for a wide variety of problems, so it 
has to be flexible enough. This is the key feature that I personally 
like about Boost, and it proved to be essential for me many many times. 
But if you want a local solution for your particular task, which may be 
more optimal in some ways than what Boost provides, you are free to 
write one.

> 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.
> 

If you had also searched Trac tickets related to windows.h inclusion in 
headers, I'm sure you'd have found quite a few problems with it. So this 
particular twist in the header has a good ground. Same with many other 
twists that you may find in the code.