[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