If I understand correctly, we can add an assertion here, and remove
the argument 'true'.
+ SaveAndRestore<bool> ResetCallbackFlag() {
+ // This looks like it's incorrect, since a non-optimizing compiler will
+ // use a temporary and a copy here, then destroy the copy and reset the
+ // value of respondsToCallback. However, the only case where
+ // respondsToCallback is 'false' is just after calling an ignored
+ // callback. By the end of the block in which a client calls that callback,
+ // the value of respondsToCallback will have been reset to 'true'.
assert(respondsToCallback);
+ return SaveAndRestore<bool>(respondsToCallback, true);
+ }
On Fri, Aug 6, 2010 at 3:14 AM, Jordy Rose <[email protected]> wrote:
> Hm. Thanks to the fact that one callback may end up indirectly invoking
> another, this is not so simple. On the one hand, it does let us track the
> response for any callback. On the other, ResetCallbackFlag is a kludge.
>
> Holding off on committing for now.
>
>
> On Wed, 4 Aug 2010 17:10:17 -0700, Ted Kremenek <[email protected]>
> wrote:
>> That's not a bad idea at all. In fact I really like it. The value can
>> still get lazily set, but just stored with the Checker object.
>>
>> On Aug 4, 2010, at 10:51 AM, Jordy Rose wrote:
>>
>>> This is not a general solution, though. Alternately, we could just
> stick
>>> the flag in Checker rather than CheckerContext.
> _______________________________________________
> cfe-commits mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
