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

[Jordy Rose]

On Mon, 31 May 2010 10:13:23 +0800, Zhongxing Xu <xuzhongxing at gmail.com>
wrote:
> On Mon, May 31, 2010 at 6:26 AM, Ted Kremenek <kremenek at apple.com>
wrote:
>> 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.

I like the idea of extents being just another symbolic value -- that
allows them to be used in assumptions and other checker things. Fits in
very well with my GSoC project.

The only reason I suggested the original association of fill values with
extents was because extents currently /are/ handled by the StoreManager,
though there is no overlap with the Store part (they're stored in the GDM),
and because SymbolicRegions are the only ones that need fill values right
now. Of course, that could change if we start modelling other standard
library functions like memset().

So, is the thing to do for {m,c}alloc() to add a Fill(Store, MemRegion*,
SVal) method to StoreManager?

Jordy