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._______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
