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

[Joerg Sonnenberger via cfe-dev]

On Fri, Aug 26, 2016 at 02:36:31PM +0000, Daniel Marjamäki wrote:
> 
> Hello!
> 
> As far as I know, having few false positives is a major goal for the Clang static analyzer.
> 
> Yes I understand that false positives are inevitable. So a few fixes in my code to hide them are expected.

A good example of unavoidable false positives is the format string
checker. There is exactly one situation where passing format string
and a separate va_list is valid: if you expand some custom format string
that doesn't take an argument (consider %m for non-syslog functions) and
you expand it in a way that correctly quotes any potential %. The
compiler can't know that and that's why it is a false positive.
The workaround in the code is to explicitly disable the warning/check
for that specific case.

> However if most warnings for a particular use case are in practice false positives I say these should be dropped. So I think the question should be if most warnings are false positives? Do you think your true positive ratio in your own code is good? Is it higher than 50%?
> 
> > But the example you have given is *not* wrong. It is completely correct.
> 
> Imho it is a false positive if I can easily see with human intelligence that the warning is wrong.

But you can't without adding additional assumptions that are not part of
the code. In this case "nr must be positive". That's why it is not a
false positive -- you have to add external knowledge. If the constraint
can't be handled by the analyzer, that's again a different situation.
That's e.g. a problem when the initialisation happens in a different
function and the analyzer can't or doesn't want to see it. Another case
is if the constraint depends on a non-trivial computation and the
analyzer isn't smart enough to figure it out. All those are examples of
false positives: the information is available, but the system doesn't
use them. It is not a false positive if information is missing in first
place.

Joerg