[cfe-commits] r91535 - in /cfe/trunk: include/clang/Analysis/PathSensitive/GRExprEngine.h include/clang/Analysis/PathSensitive/MemRegion.h include/clang/Analysis/PathSensitive/Store.h lib/Analysis/GRExprEngine.cpp lib/Analysis/MemRegion.cpp lib/A

[Ted Kremenek]

On Dec 16, 2009, at 5:47 PM, Zhongxing Xu wrote:

> 2009/12/17 Ted Kremenek <kremenek at apple.com>:
>> Hi Zhongxing,
>> 
>> How do we plan on using CXXObjectRegion?
>> 
>> For stack allocated objects, we will use VarRegions.  For heap allocated (e.g., 'new'), we will use SymbolicRegions.  For fields that are C++ objects we will use FieldRegions.
>> 
> 
> My feeling is that c++ objects may have some properties that justify
> it to be a separate region, like the vtable pointer. But apparently we
> haven't got there.

If we wanted to represent the vtable pointer we have a variety of options, like having something similar to FieldRegion, e.g., VTablePtrRegion, that allows us to attach the vtable pointer as a "property" of another region.  That way a VarRegion could represent a stack allocated object, a SymbolicRegion an objected created using 'new', etc.

> 
>> It seems that the only place where we would use CXXObjectRegions are for modeling the object associated with analyzing a specific method, but I'm not sure  that is necessary or the right approach.  ObjCObjectRegion is currently only used by BasicStoreManager, and that should probably be fixed so it can be removed.  RegionStoreManager handles the Objective-C 'self' variable by using a VarRegion for the 'self' ImplicitParamDecl, and then represents the actual Objective-C object with a SymbolicRegion.  There is no ImplicitParamDecl for 'this', but conceptually that's what we want: a way to go from CXXThisExpr to the region that represents the current object.  That way when we inline method calls we can simply map from ("this",LocationContext) -> MemRegion*.
>> 
> 
> I was looking for an identity to represent the 'this' expression, but
> haven't found one, so created a new region with the type as the
> identity.

For a given CXXThisExpr, we want to be able to map to a MemRegion representing the current object.  I don't think that requires a CXXObjectRegion; just a way to perform that query.  In other words, the region is the value we obtain from the lookup, not the key for the lookup.

My concern about introducing a new object region is that it doesn't add more power to our memory model and we run into the issue of how to model properties of objects differently for stack allocated objects and heap allocated objects.  If we perform inter-procedural analysis via inlining, for example, the 'this' pointer could refer to a VarRegion that dwells in a parent StackFrameContext.  Alternatively, if we analyzing a C++ method in isolation the 'this' pointer could be associated with a SymbolicRegion.

One idea I just had is that CXXObjectRegion could serve a function similar to the suggested VTablePtrRegion.  That is, instead of CXXObjectRegion representing the actual memory blob, it represents properties layered on that blob.  For example, we have a VarRegion or SymbolicRegion to represent the actual object, and then have CXXObjectRegion be a subregion that associates additional properties with that region (e.g., the vtable pointer).  I'm not certain if that is the right approach if we want to allow rich modeling of downcasts, as the specific type of an object referred to by a pointer might not be known, but we might have constraints on that object (e.g., it subclasses class A).  This seems difficult to model with a region that associates a specific type with an object.