haoNoQ wrote: > Unfortunately this is just "sweeping the problems under the rug" and not a > complete solution -- even if we cannot directly access the obsolete old state > object, the analyzer may still run into logically wrong behavior if methods > like `getArgSVal()` produce obsolete results from the old state.
Yeah my point is that these specific results aren't allowed to become obsolete. The argument value is looked up from the Environment. A value of an expression in Environment shall not change for as long as the expression remains live. (Dang. It's almost like this should be an assertion.) The call expression, together with its arguments, remains live until after `checkPostCall`. So even if you take the very first `CallEvent` that was fed into `checkPreCall`, the values of the arguments in that `CallEvent` would remain correct at least until the end of `checkPostCall`. Like, even if the call is inlined and an indeterminate amount of steps takes place between pre-call and post-call, it'd still be fine. Even if the callee code assigns values directly to the parameter variable, that'd only go into the Store, so the Environment in the new state would still correctly reflect the argument value from before the call, the same one as the old state. I hope that the same is true for all these actually-somewhat-irreplaceable methods provided by `CallEvent`. If not, we'll need to think of a different solution. But things like `getArgSVal()` simply don't get obsolete so easily. They're not allowed to. > so we would just write a tautologically passing check that almost looks like > `foo = bar; assert(foo == bar);` Hmm yes you're right. I was like, `CheckCallContext::runChecker()`, but looks like they already do that. So it was only a problem for `evalCall` because it's so hand-crafted. So, like, do you know whether this assertion would fail without your patch? If you stuff it into the old code and then analyze a bunch of code, would it crash a lot? https://github.com/llvm/llvm-project/pull/160707 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
