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
