What does Coverity/clang static analysis actually do?

[Walter Bright]

Nick Sabalausky wrote:
>> 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.

The difference is the maintenance programmer won't be left puzzling why 
there is an explicit assignment to the variable that is never used. The 
point to default initialization is consistency in the resulting 
behavior. Also, the optimizer will remove nearly all of the default 
initializers if they are dead assignments.

Anyhow, I think this issue was beaten to death in the previous thread on 
null dereference. I don't wish to divert this thread into rediscussing 
it, but rather stick with what other kinds of bug-detecting data flow 
analyses there are?


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

I congenitally dislike optional warnings, as I've pontificated at length 
about here before <g>. The problem is it makes for a wishy-washy 
definition of the language, and muddies what is legal versus illegal. D 
needs to advance the state of the art with clear thinking about what is 
legal and what isn't. Warnings and false positives are failures of 
language design.


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

Because when I implemented it I discovered that a compile time check 
rarely (if ever) caught actual bugs, the real problems could only be 
caught at runtime. Normally one uses things like foreach which 
automatically generate code that won't array overflow.



I generally regard as evil:

1. bugs that have erratic, random, irreproducible symptoms

2. source code that doesn't have an obvious purpose (this includes code 
inserted solely to suppress a false positive or warning)

I regard as undesirable:

3. wishy-washy warnings

4. overzealous compiler messages that are more akin to nagging than 
finding actual bugs