On Fri, 29 Jul 2011, Walter Bright wrote: > On 7/29/2011 1:30 PM, Brad Roberts wrote: > > 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. > > In general I agree with this, which is why I've made some changes to the > source code to 'fix' some of the non-bugs identified by clang. I felt the > changes made the code more readable. > > > > 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. > > So far, two real bugs have been identified. This makes it worth one pass > through the clang results, but as you say, the rate of false positives is so > high it is not worth continuing to use it.
Two real, hitable, bugs? I still look at cost/benefit.. in that same time a number of other things could be done that had at least as much direct benefit. Don't get me wrong, I really love static analysis tools, but ones that are mature and have mechanisms for managing the false positives. Later, Brad
