[cfe-commits] Checker and respondsToCallback

Zhongxing Xu xuzhongxing at gmail.com
Thu Aug 5 18:11:17 PDT 2010


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 <jediknil at belkadan.com> 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 <kremenek at apple.com>
> 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>




More information about the cfe-commits mailing list