Coverity tool

[bearophile]

Walter Bright:

>I just think that Coverity doesn't have much use for D code, because what it checks for is already covered by the language.<

I have taken a look at this report about bugs found by this tool in open source code:
http://scan.coverity.com/report/Coverity_White_Paper-Scan_Open_Source_Report_2009.pdf

The most common bugs found there by Coverity (I think they are mostly in C code):

27.8% NULL Pointer Deference
23.3% Resource Leak
 9.7% Unintentional Ignored Expressions
 8.1% Use Before Test (NULL)
 5.9% Use After Free
 5.8% Buffer Overflow (statically allocated)
 5.3% Unsafe Use of Returned NULL
 8.4% Uninitialized Values Read
 3.9% Unsafe Use of Returned Negative
 1.1% Type and Allocation Size Mismatch
 0.2% Buffer Overflow (dynamically allocated)
 0.2% Use Before Test (negative)

Key:
- Unintentional Ignored Expressions: indicates that part of the source code is not reachable on any execution path. One example involves if statements and return statements. Consider when a programmer makes a mistake in the if() statement’s test value, and the code block for the statement returns from the current function. If the test value is always true, then all the code after the if() block can never be reached.
- Unsafe Use of Returned values: results of a function are not tested if they are NULL or if they are a error value (usually negative).
- Use Before Test: similar to Unsafe Use of Returned values. When programmers test the value of a variable, this implies that they believe it is possible for the variable to have the undesired value at the point of the test. If a code path exists where the variable is used in an unsafe way before this is tested, then the test does not accomplish its objective.


Regarding D code:

- Use After Free: probably less common in D code, because dellocations are done by the GC.
- Buffer Overflows: less common in D code because of array bound tests at runtime, and because some string operations/functions are safer.
- Type and Allocation Size Mismatch: malloc/calloc are not common in D code, and the usage of the new statement avoids many bugs of this class.
- Unsafe Use of Returned error values: hopefully in all the code (but where high-performance code is necessary) D programmers use exceptions to denote error situations, avoiding some of this class of bugs.
- Resource Leak: in theory the GC can help a lot here. In practice the D GC is conservative, so it leaks by design.
- Uninitialized Values Read: D "solves" this problem initializing by default all variables. In practice probably some default-initialized values can cause troubles where a default initialization was not the right thing.
- NULL Pointer Deference: this probably happens in D code, by default class references can be null.

You can probably find the following bugs in D code:
- Use Before Test: here the bugs are in the code paths of the try-except.
- Unsafe Use of Returned NULL: the D2 type system doesn't help here.
- Unintentional Ignored Expressions


D language surely introduces new classes of bugs absent in C code. D2 has several complex and hairy features, that can lead to bugs.

------------

Ellery Newcomer:
 	
>I think a large part of the article proves your point: all those checks belong in the compiler, and not in a third party tool.<

In theory you are right, but in practice compiler writers have already their hands full, so I have nothing against the idea of a lint tool that does more tests compared to the compiler.

The new Clang/Clang++ compiler (front-end based on LLVM. Few days ago Clang++ has compiled all llvm itself) is able to perform a good amount of (simple but useful) static tests on the code, and it gives precise error messages.
Being the LLVM project very modular, with some luck a future LDC-like compiler for D2 will find a way to re-use some of the analysis modules used by Clang on D2 code, so maybe it can list unused variables, spot some cases of null reference deferences, etc.

Bye,
bearophile