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

[Ted Kremenek]

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

>>> What I didn't realize is that invalidateRegions is /only/ used for parameters.
>> 
>> I'm not certain what you mean.  It's a general API, that is meant to be used to invalidate any set of regions, starting with region roots.  invalidateRegions is also used to invalidate globals.  Yes, we use it right now to invalidate parameters, but it could certainly be used in other cases.
> 
> Sorry, I meant "only for function/method calls", i.e. running code we can't see. I'm not sure if /that's/ supposed to be in the contract either, but it makes passing around a list of "arguments" not as bad to me, since there /will/ always be arguments.

I can see invalidateRegions() possibly being used for other cases than just the standard conservative behavior of invalidating globals/parameters.  The uses would all be similar, but I don't see a reason why they would need to be restricted to parameters being invalidated.

> 
> 
>>> That means that passing the top-level parameters isn't really changing any semantics. So I'm good with (2).
>> 
>> Ah, you mean by extending the API and making it too specialized?
> 
> I don't mind specialization, I just mind having exceptional cases that have to leave fields blank. That makes me think the abstraction's at the wrong level.

That's true.

> 
> 
>>> Is it best to pass a list of SVals? A list of top-level regions? A list of expressions? A list of symbols? A CallOrObjCMessage? The last is clearly most flexible, but I'm not sure that's what we need. I feel like the list of SVals (ArrayRef<SVal>) is probably the way to go.
>> 
>> Maybe just the list of MemRegion roots and an *optional* ProgramPoint?  The latter could be used to tailor the behavior of the callback.  SVals are really one level too high, since this API really is about regions.
> 
> I guess so. What RetainReleaseChecker needs is the symbols, but the API shouldn't be tailored to RetainReleaseChecker, and it's not /that/ hard to extract symbols from MemRegions, some of which are SymbolicRegions.

The invalidated symbols can all be queried from the SymbolReaper.  The regions represent the actual locations that were used as parameters (or whatever we used for the "roots" of the invalidation).  Symbols aren't all locations, but some regions are (essentially) symbols.  Since invalidation stems from locations, regions seems a more natural starting point to me, while SVals cover too much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110825/8b0bd1ba/attachment.html>