On Mon, Oct 6, 2008 at 1:30 AM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
> > On Oct 4, 2008, at 6:49 PM, Zhongxing Xu wrote: > > > > On Sun, Oct 5, 2008 at 1:43 AM, Ted Kremenek <[EMAIL PROTECTED]> wrote: > >> >> On Oct 4, 2008, at 1:51 AM, Zhongxing Xu wrote: >> >> If we do not intend to support locations other than simple scalar >>> variables in BasicStoreManager, we can make it more explicit by using >>> VarRegionVal instead of MemRegionVal. >>> >>> -Zhongxing XU >>> >> >> >> Hi Zhongxing, >> >> The RValues interfaces is meant to be usable by different subclasses of >> StoreManager, not just BasicStoreManager. That's why I used MemRegionVal >> instead of VarRegionVal. We have VarRegion to distinguish a variable region >> from one region and another. The main objective of getting rid of DeclVal >> (which was replaced with MemRegionVal) was so that clients (e.g., >> BugReporter, specific checks) stopped thinking about just variables and >> started reasoning about generic chunks of memory. >> >> Ted > > > You mean we will not have other *RegionVals than MemRegionVal, and let the > client use dyn_cast to reason about the kind of the underlying region? > > > Another reason not to create RVals for each region: we may wish to have > implementations of StoreManager create their own region types that are not > known to external clients. > That makes sense.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
