What does Coverity/clang static analysis actually do?

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:ha2run$275r$1 at digitalmars.com...
>
> 1. dereference of NULL pointers (all reaching definitions of a pointer are 
> NULL)
> 1. Optimizer discovers it, but ignores the information. Due to the recent 
> thread on it, I added a report for it for D (still ignored for C). The 
> downside is I can no longer use *cast(char*)0=0 to drop me into the 
> debugger, but I can live with that as assert(0) will do the same thing.
>

Sounds like a nice start.

> 2. possible dereference of NULL pointers (some reaching definitions of a 
> pointer are NULL)
> 2. Optimizer collects the info, but ignores this, because people are 
> annoyed by false positives.
>

If you mean something like this:

Foo f;
if(cond)
    f = new Foo();
f.bar();

Then I *want* the compiler to tell me. C# does this and I've never been 
annoyed by it, in fact I've always appreciated it. I'm not aware of any 
other C# user that has a problem with that either. If that's not what you 
mean though, then could you elaborate?

> 3. use of uninitialized variables (no reaching definition)
> 3. Optimizer detects and reports it. Irrelevant for D, though, because 
> variables are always initialized. The =void case is rare enough to be 
> irrelevant.
>

D variable default-initialization is absolutely no different from your 
scenario of a programmer blindly tossing in =0 to shut up a compiler, 
*except* that the programmer is never even given the opportunity to do the 
right thing. This is *bad*. I *want* variables that haven't meen manually 
inited to be statically treated as uninited. C# does this and it works 
great.

> 4. dead assignments (assignment of a value to a variable that is never 
> subsequently used)
> 4. Dead assignments are automatically detected and removed. I'm not 
> convinced this should be reported, as it can legitimately happen when 
> generating source code. Generating false positives annoy the heck out of 
> users.
>

I'll agree with you here. But it might be nice to have an option to just 
simply report them anyway for when the programmer wants to see if there's 
any of these around that he can clean up.

> 5. dead code (code that can never be executed)
> 5. Dead code is detected and silently removed by optimizer. dmd front end 
> will complain about dead code.
>

Cool.

> 6. array overflows
> 6. Arrays are solidly covered by a runtime check. There is code in the 
> optimizer to detect many cases of overflows at compile time, but the code 
> is currently disabled because the runtime check covers 100% of the cases.
>

I'm puzzled by why you would prefer to leave this entirely runtime when some 
of it can be detected at compile-time. Normally you agree that catching 
something at compile-time is better whenever possible. So shouldn't the 
array overflows that can be detected at compile-time be detected at 
compile-time? I would certainly prefer that.

> 7. proper pairing of allocate/deallocate function calls
> 7. Not done because it requires the user to specify what the paired 
> functions are. Given this info, it is rather simple to graft onto existing 
> data flow analysis.
>

Interesting idea. D's scope(){} does help a lot, but I wouldn't be opposed 
to this extra protection to make sure I remember to use scope.

> 8. improper use of signed integers (who knows what this actually is)
> 8. D2 has acquired some decent checking for this.
>

Hooray for D :)

> There's a lot of hoopla about these static checkers, but I'm not impressed 
> by them based on what I can find out about them. What do you know about 
> what these checkers do that is not on this list?

Sorry, I don't know anything about them.

> Any other kinds of checking that would be great to implement?
>

http://d.puremagic.com/issues/show_bug.cgi?id=2197