Rarely I have found a so fun description of a software, how they can (barely?) make it a commercial product, the problems they find. The program is a bug finding tool, for C, C++, Java, C#:
http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext

I think it's an interesting read for people that are creating a new language :-)

Bye,
bearophile

bearophile wrote:
> Rarely I have found a so fun description of a software, how they can
> (barely?) make it a commercial product, the problems they find. The
> program is a bug finding tool, for C, C++, Java, C#: http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext
> 
> 
> I think it's an interesting read for people that are creating a new
> language :-)


Coverity's business model seems to be based on being very vague about what their software actually does, and being even more evasive about what they charge to use it.

From what I can infer from their various statements, the primary thing it does is pair functions that must be paired, like malloc/free, lock/unlock, fopen/fclose, etc.

This is ably handled in D using the scope guard statement.

It does some other things like very limited array bounds checking, also already handled by D which does full array bounds checking.

Walter Bright wrote:
> Coverity's business model seems to be based on being very vague about what their software actually does,


Found some stuff on the Cert web site:

https://www.securecoding.cert.org/confluence/display/seccode/Coverity+Prevent

Walter Bright:
>  From what I can infer from their various statements, the primary thing
> it does is pair functions that must be paired, like malloc/free,
> lock/unlock, fopen/fclose, etc.

I have never used their program, and probably I will never buy it, but I have seen it used two times on the whole source code of CPython, and it has found a good amount of bugs (that devs have fixed in some weeks) despite such C sources are sometimes quite good (see for example: http://svn.python.org/view/python/trunk/Modules/_collectionsmodule.c?view=markup ) compared to the messy C sources of Perl or Ruby. So it's an useful tool. Using D2 compiled with DMD is not an option for CPython devs, they can't even use C99.

Bye,
bearophile

bearophile wrote:
> Walter Bright:
>> From what I can infer from their various statements, the primary
>> thing it does is pair functions that must be paired, like
>> malloc/free, lock/unlock, fopen/fclose, etc.
> 
> I have never used their program, and probably I will never buy it,
> but I have seen it used two times on the whole source code of
> CPython, and it has found a good amount of bugs (that devs have fixed
> in some weeks) despite such C sources are sometimes quite good (see
> for example:
> http://svn.python.org/view/python/trunk/Modules/_collectionsmodule.c?view=markup
> ) compared to the messy C sources of Perl or Ruby. So it's an useful
> tool. Using D2 compiled with DMD is not an option for CPython devs,
> they can't even use C99.


I'm not disagreeing with you, I just think that Coverity doesn't have much use for D code, because what it checks for is already covered by the language.

On 02/09/2010 02:18 PM, Walter Bright wrote:
> bearophile wrote:
>> Walter Bright:
>>> From what I can infer from their various statements, the primary
>>> thing it does is pair functions that must be paired, like
>>> malloc/free, lock/unlock, fopen/fclose, etc.
>>
>> I have never used their program, and probably I will never buy it,
>> but I have seen it used two times on the whole source code of
>> CPython, and it has found a good amount of bugs (that devs have fixed
>> in some weeks) despite such C sources are sometimes quite good (see
>> for example:
>> http://svn.python.org/view/python/trunk/Modules/_collectionsmodule.c?view=markup
>>
>> ) compared to the messy C sources of Perl or Ruby. So it's an useful
>> tool. Using D2 compiled with DMD is not an option for CPython devs,
>> they can't even use C99.
>
>
> I'm not disagreeing with you, 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 think a large part of the article proves your point: all those checks belong in the compiler, and not in a third party tool.

Still, there are lots of trivial or nontrivial or fuzzy or advanced analyses that DMD doesn't perform. A dumb example would be

version(1){
    pragma(msg, "1");
}else version(2){
    pragma(msg, "2");
}

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

bearophile wrote:
> 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.

@safe guarantees memory safety, so these are non-issues in D.


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

Using @safe makes these non-issues.


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

As you say, exceptions solve these problems.


> - Resource Leak: in
> theory the GC can help a lot here. In practice the D GC is
> conservative, so it leaks by design.

It is a mistake to rely on the GC to free resources other than memory. Properly, either RAII or scope guard statements should be used, as these do not leak.


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

No analysis tool can help you if you initialize things to the wrong value. That's very, very different from initializing things to GARBAGE and then using those garbage values.


> - NULL Pointer Deference: this probably happens in D code, by default class
> references can be null.

We've certainly had long threads about this one. I'll just state that turning on the optimizer will detect many cases of dereferencing null pointers.


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

Not sure what this means.


> - Unsafe Use of Returned NULL: the D2 type system doesn't help here.

Not sure what this means.


> - Unintentional Ignored Expressions

dmd already flags dead code.

Walter Bright:

>@safe guarantees memory safety, so these are non-issues in D.<

I think people want to use D instead of Java/C# for (when necessary) its lower level features, because if they don't need that extra little percentage of performance they probably want to use Java/C# in the first place, that have many more tools, software, cheap developers, etc. So D programs probably will contain some unsafe code. Of course in a D project a smart programmer tries to minimize the amount of unsafe lines of code.
So a lint tool (or a better compiler) to spot those bugs in unsafe D code can be useful.


>As you say, exceptions solve these problems.<

But there are many C++ programmers that don't use exceptions, for example they are not allowed in Google C++ code:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
So surely not 100% of D code will use exceptions. That's why I have said that D avoids some of those problems but not all them :-)



>>- Resource Leak: in theory the GC can help a lot here. In practice the D GC is conservative, so it leaks by design.<<

>It is a mistake to rely on the GC to free resources other than memory. Properly, either RAII or scope guard statements should be used, as these do not leak.<

I was saying that by design a conservative GC can leak memory, and I have seen that it actually does it if the programs allocates lot of memory.



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

>No analysis tool can help you if you initialize things to the wrong value. That's very, very different from initializing things to GARBAGE and then using those garbage values.<

What I meant is that I really like when the Java compiler tells me that a variable is not initialized :-)



>I'll just state that turning on the optimizer will detect many cases of dereferencing null pointers.<

Very good, and future D compilers can improve some more on this :-)



>>- Unsafe Use of Returned NULL: the D2 type system doesn't help here.<<
>Not sure what this means.<

I meant that in D2 the type system doesn't support nonnullable references yet. Not-nullable references/pointers can't be null, so there's no need for the programmer to remember to test if they are null, so I think they can avoid some bugs caused by untested nulls. In practice I have never programmed with a language with this feature so I don't know what side effects it can have.



>>- Use Before Test: here the bugs are in the code paths of the try-except.<<
>Not sure what this means.<

Thinking more about it, I think I was probably wrong.

Thank you for your answers, as usual I am often wrong and you are usually right; I am not even remotely as good as you, but I try to help :-)

Bye,
bearophile

>> - Use Before Test: here the bugs are in the code paths of the try-except.
>
> Not sure what this means.

If I remember correctly from when I had an opportunity to look at these types of tools, this is a case where, in C or C++, you have a variable that may be uninitialized or set to NULL, but you don't test for it until you have tried to use it.  I believe the root cause of this bug has nothing to do with the language, but with people going back into code they don't fully understand and trying to either A) use the variable and not know that the check is in there or B) they put the check in to "fix" a bug, but didn't put it in the correct spot.

Needless to say, with D setting variables to reasonable defaults, I believe this is mitigated, but not entirely prevented.