On Sat, Aug 7, 2010 at 8:43 AM, Ted Kremenek <[email protected]> wrote: > On Aug 5, 2010, at 10:27 PM, Jordy Rose wrote: > >> Checkers aren't currently stateless, but they probably ought to be much >> more so, especially for external inlining. >> >> Anyway, since Assume triggers ProcessAssume, we already have a problem -- >> many many checkers use Assume. > > Excellent point. > >> We could take the optimization out of these >> "subordinate" checks, but that sort of defeats the purpose. > > It gets even worse; a responder to ProcessAssume could in turn call 'Assume'. > I mainly see this reentrancy problem in the 'Filters' callbacks. Filters > are basically responses to state mutation, and since they can mutate the > state, they may be recursive.
Wouldn't this cause infinite loop? Maybe we'd better forbid this. The "full visits" and "evaluations" probably won't have this problem in practice. > >> >> Maybe CheckerContext needs to be a hierarchy. We could make the base >> context very small (perhaps just the flag) and add to it for the various >> callbacks. It's a little silly because it's sort of shadowing the >> callbacks, but it could solve two problems: having a local context for >> each >> invocation to store the respondsToCallback flag, and having a common >> method >> signature for all the callbacks, to allow us to package the >> visit-and-cache >> logic in its own method(s). (A possible solution to the problem discussed >> on another thread.) > > I'm a fan of this idea. We'll likely extend the CheckerContext interface in > the future (even for the base context), so overall I think it's a net win. > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
