[cfe-dev] RFC clang analyzer false positives?

Daniel Marjamäki via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 25 00:23:30 PDT 2016


Hello!

We try to avoid false positives in the static analyzer. In my opinion we should try pretty hard. When there is reason for doubt, I would say it's better with false negatives.

I wonder what you think about these.

 1. Dead store

 ...
     default: // should not happen    
          x = 0;
          ASSERT(FALSE);  // <- dead store, x is assigned a value that is not read
      }
      return x;
 }

In certain configurations the execution is terminated and then the dead store is correct. But in other configurations the "x" value will be returned.

Do you think that it would be acceptable to skip the warning if the noreturn function is in a macro call? And ideally we would warn if the value is not used after the macro but that might be quite hard to achieve (I did not look but it's my assumption).


 2. Garbage value.

     #define INVALID ~0
     struct XY { int x; int y; };
     
     inline struct XY getXY(int index) {
       struct XY xy;
       if (index < 12) {
         xy.x = 1;
         xy.y = 2;
       } else {
         xy.x = INVALID;
       }
       return xy;
     }
     
     void f(int index) {
       struct XY xy;
       xy = getXY(index);
       if (xy.y == 0) {}   // <- garbage value xy.y
     }

In the real code the "getXY" function is implemented in a header and can be called from many locations.

Clang assumes that the condition "index < 12" in getXY() can be false. Should such assumption really be made since it's a subfunction declared in a header that might be called from many places? If the condition was moved to f() I would agree that we can assume that it can be false - otherwise it would be useless to have it.

I believe we could solve this FP in our code by adding an assertion in f() that makes sure index is less than 12. However such assertion would be misplaced. We want to validate input values as soon as possible. The "index" is validated long before the function f() is called.

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



More information about the cfe-dev mailing list