Coverity tool

[Walter Bright]

Brad Roberts wrote:
> Nice black and white world you are acting like you live in there Walter.  
> I know you know better, so why do you pretend otherwise?

First off, yes, if you program in C style, despite using D, your code is 
vulnerable to many of the problems that Coverity detects.

> You're assuming perfect use of the language and largely simple code.  
> Granted, there's a lot of things that D does better, and the tools in the 
> language make it easier to write better code... but developers are corner 
> cutters at heart.  Additionally, not everything can be done in @safe (or 
> it wouldn't be an optional mode), and not everything can use RAII for 
> resource management.

Yes, I am relying on convention to a degree for D to be helpful, and 
I've often enough railed against relying on convention. So why the 
contradiction?

Let's take the lock()/unlock() pairing problem. In C, you often wind up 
with a rat's nest of control flow that gets really hard to verify has 
the unlock() along all paths. Coverity is a win here. In C++, you can 
wrap the lock()/unlock() in a struct and use RAII, but that's as ugly as 
sin and many will eschew it, thus Coverity wins again. But in D,

     lock();
     scope(exit) unlock();

and you're done. There's nothing left to analyze. Nothing makes you 
write D code that way, but I contend that it is easy to write it that 
way (which addresses the corner cutters), and it is easy for a code 
review to verify it. No tangle of logic must be traced. So the problem 
is reduced from a 10 to a 1. It doesn't go away, but the payback of 
Coverity for these cases is greatly reduced.

(And the cost of Coverity isn't just the purchase price, it has 
significant administration and false positive costs.)

About @safe: a lot of Coverity is focussed on memory safety, for example 
it spends a lot of effort analyzing use of C string functions. With 
@safe, the D compiler guarantees your code is memory safe. No false 
positives. The idea is to reduce the @system parts of your code to as 
small a fraction as possible. Then, you aren't running a million lines 
of code through Coverity to check for memory safety, you're running only 
a few percent of it, and those few percent will be a lot easier to review.


> Compilers do, in concept, a lot of the things that Coverity does, but at a 
> very different scale.  Coverty is aimed at whole application long range 
> effect analysis.  It's got good tools for over-time analysis of builds to 
> help ensure incremental improvements (ie, prevent quality slipping 
> backwards).  All in all, it's well engineered for large systems and large 
> teams.
> 
> I wish I had access to it for everthing I develop.  Sadly, the cost is too 
> high.

D has moved a lot towards supplying by default a lot of what Coverity 
claims to do. By making such an expensive tool irrelevant for D, we can 
make D much more cost effective.