[cfe-dev] CFRefCount Problem #2: Region Invalidation

[Ted Kremenek]

On Aug 24, 2011, at 11:55 AM, Jordy Rose wrote:

> Oh! I meant RefBindings (i.e. ref count state), not store bindings. Sorry!
> 
> Basic idea was this:
> - invalidation (without whitelist) wipes out reference counts
> - in postCall, walk backwards in the graph to before the call is evaluated (using the ProgramPoint)
> - look up each argument's refcount in the old node and copy it to the new node
> - apply the call's ArgEffects to its arguments (as is done now)
> 
> This doesn't handle the recursive data structure case, but even if an object has a strong reference to itself it's probably /still/ following retain-count conventions. I think it's okay for RetainReleaseChecker not to handle that case.

Ah, ok.  That makes a lot more sense.

In general, I'm not a fan of such post-processing.  I'd rather design an API where the checker can make the right decision upfront instead of separating the logic in such a disjoint way between the callback for invalidateRegions and the callback for post-visiting a CallExpr.

Here are the problems I see:

(1) The logic is disjoint.

(2) It is error prone and messy.  Checkers generally shouldn't need to grovel through the predecessors in the ExplodedGraph in order to implement basic functionality.  Generally speaking, checkers should be written so that the transfer functions are "memoryless".  They should take the current expression, the current ProgramState, and produce a new ProgramState.  That's it.  Anything else is a departure from that clean model.

(3) It introduces semantic inconsistencies.  Say two checkers consult the same checker meta-data associated with symbols.  If one callback we invalidate the symbols, and then the other checker possibly sees no checker meta-data before the other checker adds it back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110825/453ebe7e/attachment.html>