<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Oct 20, 2008 at 12:51 PM, Zhongxing Xu <span dir="ltr"><<a href="mailto:xuzhongxing@gmail.com">xuzhongxing@gmail.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 dir="ltr"><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Mon, Oct 20, 2008 at 12:48 PM, Zhongxing Xu <span dir="ltr"><<a href="mailto:xuzhongxing@gmail.com" target="_blank">xuzhongxing@gmail.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 dir="ltr"><br><br><div class="gmail_quote"><div>On Mon, Oct 20, 2008 at 12:28 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com" target="_blank">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><br>
On Oct 19, 2008, at 6:24 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;">
1. Initial support for local arrays in RegionStoreManager::AddDecl()<br>
2. Move special processing of loading array variable's lvalue from GRExprEngine to Store. This simplifies code. And this is also what we have to do when we processing code like:<br>
</blockquote>
<br></div>
Hi Zhongxing,<br>
<br>
The following down cast is not necessary, as R is a VarRegion:</blockquote></div><div><br>Fixed.<br> </div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
+++ lib/Analysis/BasicStore.cpp （工作副本）<br>
@@ -42,7 +42,6 @@<br>
<br>
virtual MemRegionManager& getRegionManager() { return MRMgr; }<br>
<br>
- // FIXME: Investigate what is using this. This method should be removed.<br>
virtual Loc getLoc(const VarDecl* VD) {<br>
return loc::MemRegionVal(MRMgr.getVarRegion(VD));<br>
}<br>
@@ -148,7 +147,15 @@<br>
<br>
if (!R)<br>
return UnknownVal();<br>
-<br>
+<br>
+ // We let an array variable's rvalue be its lvalue, because we have to<br>
+ // process code like: int a[10]; int (*p)[10]; p = &a; (*p)[3] = 1; The<br>
+ // other benifit is that we can save the special handling of array<br>
+ // variables in VisitDeclRefExpr().<br>
+ if (const VarRegion* VR = dyn_cast<VarRegion>(R))<br>
+ if (VR->getDecl()->getType()->isArrayType())<br>
+ return LV;<br>
+<br>
<br>
I'm also not certain why this logic is needed (or if it is correct). The expression '&a' is handled by VisitUnaryOperator, and for the case of '&' it calls VisitLValue on its subexpression. I don't see where a call to GetSVal is involved.<br>
<br>
The cleanups to GRExprEngine are very nice.<br>
<br>
All in all the patch looks good, but I am a little unclear about why BasicStore::GetSVal should return the lvalue for an array in an rvalue context. GRExprEngine handles the implicit conversions between lvalues and rvalues, not the store.<br>
<br>
</blockquote></div></div>When we visit (*p)[3] = 1, we evaluate (*p)'s rvalue. We will do a load on p's rvalue, which is loc::MemRegionVal(region of a). We want (*p)'s rvalue still be loc::MemRegionVal(region of a). So we should handle this in Store.<br>
</div>
</blockquote></div><br></div></div>It's actually a special "load" not going through the binding.<br></div>
</blockquote></div><br>As a more direct example, consider code<br><br>int a[10];<br>a[1] = 3;<br><br>When we visit a[1], we evaluate a's rvalue. In VisitDeclRefExpr, we first get a's lvalue loc::MemRegionVal(a's region), then do a load on it. We expect to load loc::MemRegionVal(a's region) from itself. Then a ImplicitCast will convert it to a pointer to a's first element.<br>
</div>