<br><br><div class="gmail_quote">On Mon, May 31, 2010 at 6:26 AM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
On May 30, 2010, at 3:13 PM, Jordy Rose wrote:<br>
<br>
> The more the thread goes, though, the more I dislike this overloading of<br>
> Bind() -- again, I realize I should have thought more about design<br>
> beforehand, not just "make it work". Do either of the other designs make<br>
> more sense to you?<br>
> 1. New method on StoreManager for setting default values.<br>
> 2. Adding a parameter to SetExtent() for setting default values.<br>
<br>
</div>The notion of direct and default values is something internal to RegionStore.  There's no reason that GRExprEngine needs to be concerned about those details.  Direct and default bindings exist so that RegionStoreManager can lazily represent some of the bindings in memory without having to maintain explicit bindings (as is the case in BasicStoreManager).  For (1), there's no reason to extend the interface for StoreManagers beyond loads and stores.<br>

<br>
Extents are a different issue.<br>
<br>
I believe we should have a separate map for region extents, but that doesn't need to be part of the StoreManager.  Indeed keeping extents out of the StoreManager (but allowing the StoreManager to query extents) would allow one representation of extents that can be used by different StoreManagers.<br>

<br>
Explicit extents are only needed for SymbolicRegions, as all other extents can be derived either from the definition of the region itself (e.g., a VarRegion) or from the super region of a region.<br>
<br>
For symbolic regions, an extent would require a mapping from the symbol of that region to the size.  That size can be a symbolic value in itself.<br>
<br>
Actually, extents for symbolic regions can be just another kind of "derived symbol", which is a symbol derived from another, which means extents can be lazily queried from the SymbolManager.  Then the ConstraintManager can report back any information it has on that extent.  We can then paper over a simple API that clients can query to get an extent given a region and a GRState (which holds the current symbolic constraints).<br>

<br>
In either case, I don't see a need for the StoreManager to get into the business of managing extents.  The StoreManager has a "simple" task of just managing the actual bindings.  By keeping this simple, we get a nice separation of concerns between the components of the analyzer and we are free to substitute new StoreManages as we come up with new ways to represent bindings efficiently.</blockquote>
</div><br>This is an interesting idea. I'll think about it more.<br>