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?
Yes, exactly! It just seems conceptually cleaner, has the same run-
time overhead, and doesn't mean we have to add a new RVal every time
we add a new region type._______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
