[PATCH] D37120: [analyzer] Fix modeling arithmetic

Alexander Shaposhnikov via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 25 11:17:19 PDT 2017


alexshap added inline comments.


================
Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:371-373
+            return makeSymExprValNN(
+                state, op, lhs.castAs<nonloc::LocAsInteger>(),
+                rhs.castAs<nonloc::ConcreteInt>(), resultTy);
----------------
NoQ wrote:
> For now this code would return `UnknownVal` in most cases (pointer is not tainted, or not symbolic, or contains an offset), and still construct an invalid symbol in the rest of the cases (`makeSymExprValNN` would add the number to the pointer symbol, instead of modelling an offset within the pointed-to region).
> 
> Once D35450 finally lands (sorry for the delays...), it'd return `UnknownVal` less often and crash more often.
@NoQ - many thanks for the code review!

i assume i might be missing smth, anyway, (replying to this comment and another one below)

  >This is probably the way to go: just take the Loc behind the LocAsInteger, cast it to char * (because 
  >pointer type shouldn't affect how much bytes of offset are added, anymore), add your integer to it, 
  >pack back into LocAsInteger

i'm not sure i understand how that would work here and somehow don't like it. 
For example, op can be MultiplicativeOp (i.e. long y = ((long)p) * 13;) extracting the Loc and doing smth with the Loc -  doesn't seem to be the right thing (if i understood your suggestion correctly)

  >For now this code would return UnknownVal in 
  >most cases (pointer is not tainted, or not symbolic, 
  >or contains an offset)

that was my understanding what this code should do (return UnknownVal in most cases unless we can reason about the actual (integer) values of LHS,RHS)




Repository:
  rL LLVM

https://reviews.llvm.org/D37120





More information about the cfe-commits mailing list