<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 4, 2008, at 6:49 PM, Zhongxing Xu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><br><div class="gmail_quote">On Sun, Oct 5, 2008 at 1:43 AM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d"><br> On Oct 4, 2008, at 1:51 AM, Zhongxing Xu wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.<br> <br> -Zhongxing XU<br> </blockquote> <br> <br></div> Hi Zhongxing,<br> <br> 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.<br> <font color="#888888"> <br> Ted</font></blockquote><div><br>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?<br></div></div></div></blockquote></div><br><div>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.</div></body></html>