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

[Daniel Marjamäki via cfe-dev]

Hello!

I am not against that those warnings are available _also_. Imho the heuristic is too noisy for me right now so I would be happier if I could personally disable that for now. Move the heuristic to alpha or something.

> I've seen the analyzer find real problems where loops are not executed and think this is very useful. Personally I'd rather see the warnings and add asserts, which makes it clearer that 'nr' must be greater than 1, making it less likely someone will add an incorrect call in the future. While that is a preference for avoiding false negatives over false positives, I think it is reasonable in this case given there is no analysis across translation units.

I am trying to introduce Clang analyzer on an existing large code base and they don't want to see any false positives. I would ideally like to have very restrictive checking for uninitialized variables right now.

It is acceptable to add _some_ assertions and annotations to achieve no false positives. But I'm afraid it looks bad that most of the warnings are wrong right now.

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<mailto:Daniel.Marjamaki at evidente.se>@evidente.se<mailto:Daniel.Marjamaki at evidente.se>

www.evidente.se
________________________________
Från: Piotr Padlewski [piotrekpad at gmail.com]
Skickat: den 25 augusti 2016 19:07
Till: Sean Eveson
Kopia: Clang Dev; Daniel Marjamäki
Ämne: Re: [cfe-dev] RFC clang analyzer false positives (for loop)

I totally agree. If you have such constrain then you should express it in code, for example using do-while or assert, or why just not initialize the value?

On Aug 25, 2016 08:15, "Sean Eveson via cfe-dev" <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Hi,

I've seen the analyzer find real problems where loops are not executed and think this is very useful. Personally I'd rather see the warnings and add asserts, which makes it clearer that 'nr' must be greater than 1, making it less likely someone will add an incorrect call in the future. While that is a preference for avoiding false negatives over false positives, I think it is reasonable in this case given there is no analysis across translation units.

You tend to get false positives when the Analyzer can't see any calls to the function, so doesn't know 'nr' can never be less than 1. You can get false negatives when the analyzer can only see some of the calls.

Sean Eveson
SN Systems - Sony Computer Entertainment Group

On Thu, Aug 25, 2016 at 8:55 AM, Daniel Marjamäki via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Hello!

One more email about false positives.

I see many false positives in code like this:

    int f(int nr) {
      int x;
      for (int i = 0; i < nr; ++i) {
        x = i;
      }
      return x;
    }

Theoretically, if "nr" is less than 0 then the return value will be uninitialized.

As far as I have seen we know that such loops are executed at least once very often. I can't remember a TP where it was possible that such loop code would not be executed.

Can we try to fix this so the analyzer will be silent for the above code? I would like that if the variable is unconditionally written in the loop code there should be no warning.

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<tel:%2B46%20%280%29709%2012%2042%2062>
E-mail:                 Daniel.Marjamaki at evidente.se<mailto:Daniel.Marjamaki at evidente.se>

www.evidente.se<http://www.evidente.se>
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160826/ab24ef4a/attachment.html>