Clang static analysis results for dmd

[Brad Roberts]

On Fri, 29 Jul 2011, Walter Bright wrote:

> Here's another one:
> 
>    T* p;
>    ...
>    if (A)
>        p = &t;
>    ...
>    if (B)
>        ... *p ...
> 
> B is true if and only if A is true. B can even be the same expression as A,
> such as a->b->c. Clang complains on the *p that p is "uninitialized". Ok, so I
> rewrite as:
> 
>    T* p = NULL;
>    ...
>    if (A)
>        p = &t;
>    ...
>    if (B)
>        ... *p ...
> 
> but now clang says I'm dereferencing a NULL pointer. At this point, I'm faced
> with some significant trial-and-error refactoring to get rid of the message.
> 
> At what point does this cease to be fixing "bugs" and become "contort to fit
> clang's quirks"?

I look at it in (at last) two ways which are are contradictory..

1) static analysis reported issues are of materialy less value than a bug 
report that comes with a repro case.  reason: the analysis doesn't have a 
test case that can prove it stays fixed short of integrating the tool as 
part of the test process -- an almost pointless exercise unless there's 
additional tooling around it to mask out false positives.

2) if the tool has trouble analyzing the code, there's a not unreasonable 
chance a person also has trouble.  The above case is a good one where 
depending on how close those two if's are in the code and how obvious it 
is that B is a super set of A, it's the kind of thing someone's going to 
have trouble with too.

By and large though, this isn't the way I'd spend my time, unless you goal 
is to reduce test cases to feed into clang to improve it.  The 
cost/benefit ratio just doesn't meet the bar.

My 2 cents,
Brad