[cfe-commits] Checker and respondsToCallback

[Zhongxing Xu]

On Sat, Aug 7, 2010 at 8:43 AM, Ted Kremenek <kremenek at apple.com> 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.
>
>