[cfe-dev] RFC clang analyzer false positives (for loop)

[Daniel Marjamäki via cfe-dev]

Hello!

> Couldn’t there be a “mode” where the analyzer would only report when it finds a patch where the condition happens.

Yes that sounds very useful.

> That may suppress a large number of "true positives” indeed, but if you start on a “dirty” codebase that may be useful to focus on “real” issues.

Yes exactly.

Best regards,
Daniel Marjamäki

..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden

Mobile:                 +46 (0)709 12 42 62
E-mail:                 Daniel.Marjamaki at evidente.se

www.evidente.se

________________________________________
Från: cfe-dev [cfe-dev-bounces at lists.llvm.org] för Mehdi Amini via cfe-dev [cfe-dev at lists.llvm.org]
Skickat: den 26 augusti 2016 18:05
Till: Artem Dergachev
Kopia: cfe-dev at lists.llvm.org
Ämne: Re: [cfe-dev] RFC clang analyzer false positives (for loop)

> On Aug 26, 2016, at 8:28 AM, Artem Dergachev via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>
> On 8/26/16 3:19 PM, Joerg Sonnenberger via cfe-dev wrote:
>> If they don't want to see any false positives, they shouldn't even ask
>> the compiler for warnings. It is a completely absurd constraint to put
>> on any analysis system. The trick for tools like Coverity and where the
>> majority of the research budget goes is to develop heuristics on what
>> false positives should be silently dropped.
>
> While false positives are obviously inevitable (there are various well-known reasons for the clang static analyzer's technique to have false positives; even outside the reach of halting problem), there are reasons why false positives are destructive:
>
> (1) If a new user takes the tool, picks 3-4 positives and finds that they're all false, she may never give the tool another chance.
> (2) If you have 1% false positives on your codebase, it means that there's a pattern that the tool fails upon; but there might be another codebase on which that pattern is popular and you'd get thousands of warnings with 100% false positive rate.
>
> So yeah, we inevitably have to treat every false positive as carefully as possible, much more carefully than false negatives. That said, ugly heuristics are rarely the best choice, yeah.


Couldn’t there be a “mode” where the analyzer would only report when it finds a patch where the condition happens.
I.e. instead of considering “I don’t know what is the possible value for nr so I complain about a possible error”, having the alternate behavior of “I know that there is a path where nr can be <= 0 and the loop not executed so I complain”.

That may suppress a large number of "true positives” indeed, but if you start on a “dirty” codebase that may be useful to focus on “real” issues.

—
Mehdi

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev