Coverity tool

[bearophile]

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