[cfe-dev] Symbolic Extents

[Jordy Rose]

On Tue, 29 Jun 2010 10:24:57 -0700, Ted Kremenek <kremenek at apple.com>
wrote:
> On Jun 28, 2010, at 11:35 PM, Jordy Rose wrote:
> 
>> Perhaps a MetadataRegion might be more appropriate? The advantage of a
>> new
>> region over a new symbol is that it could be used for metadata that
>> changes
>> as well. (I'm looking ahead to taking a stab at modeling C string
length,
>> at least in simple cases.) Of course, this could wreak havoc with the
>> mythical FlatRegionStore, which would have no place to put this new
>> subregion.
> 
> Would precisely would a MetadataRegion represent?  Regions are suppose
to
> represent chunks of memory, subsets of chunks of memory, with
annotations
> on that chunk.  Aside from VLAs (where we need to capture more
information
> anyway), I don't know what a MetadataRegion would represent.

I was trying to think of a way to leverage the existing symbol/region
liveness analysis -- subregions remain alive with the superregion, and
region values remain alive with their regions. This shouldn't be a
constraint on us, though -- a symbolic extent is just a (possibly conjured)
value that remains live with the region.

I'll stop trying to plan ahead for C string length -- maybe that's
solvable with the GDM anyway.

So, at this point I would picture extents for SymbolicRegions (and
AllocaRegions, and maybe VLAs) as a cross between derived symbols and
conjured symbols with tags, except for one possible issue -- they might be
different on different paths through the CFG. With conjured symbols now we
have a Count parameter to avoid this. Does this mean we can only
getExtent() (or getExtentVal()) from a function with access to
GRStmtNodeBuilder?

Also, it might be nice if getExtent() lived on MemRegion, instead of
ValueManager or SValuator. Maybe?