[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

Zhongxing Xu xuzhongxing at gmail.com
Wed Dec 16 17:47:33 PST 2009


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.

> 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.




More information about the cfe-commits mailing list