[cfe-commits] [PATCH] Fix for PR7218, and analyzer support for calloc()

[Zhongxing Xu]

On Mon, May 31, 2010 at 6:26 AM, Ted Kremenek <kremenek at apple.com> wrote:

>
> On May 30, 2010, at 3:13 PM, Jordy Rose wrote:
>
> > The more the thread goes, though, the more I dislike this overloading of
> > Bind() -- again, I realize I should have thought more about design
> > beforehand, not just "make it work". Do either of the other designs make
> > more sense to you?
> > 1. New method on StoreManager for setting default values.
> > 2. Adding a parameter to SetExtent() for setting default values.
>
> 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.
>
> Extents are a different issue.
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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.


This is an interesting idea. I'll think about it more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100531/0085d531/attachment.html>