[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 13 11:43:34 PST 2019


NoQ added a comment.

In D69662#1736601 <https://reviews.llvm.org/D69662#1736601>, @balazske wrote:

> Anyway the checks that do not use BindExpr (all except the open functions) could be moved into a PreCall or PostCall callback?


Moving from evalCall to PreCall/PostCall has the additional effect of not giving you control over invalidation of the heap (unless you do evalCall in a checker, it ends up being the normal behavior of `conservativeEvalCall()` most of the time). For that reason ideally every library function should be evalCall'ed by a checker.

Also if you're making updates to the program state that other checkers should see immediately (say, writing out-parameter values into the Store or updating a state trait that other checkers will read in the same callback), you should either use evalCall for that, or make sure your dependencies are set up correctly (@Szelethus, our callback invocation order is now affected by checker dependencies, right?).

`checkArgNullStream()` should definitely be at PreCall.

`evalFseek()` doesn't have a `BindExpr` but it //should// have it; looks like a bug. If you're evalCall-ing a non-void function you //must// bind a return value (we should add an assertion for this; there's never a reason to bind an `UnknownVal` in evalCall because there generally never is a good reason to bind `UnknownVal` to anything because it shouldn't have been present in our `SVal` hierarchy in the first place because conjuring a value is always strictly better).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69662/new/

https://reviews.llvm.org/D69662





More information about the cfe-commits mailing list