<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Oct 20, 2008 at 2:38 PM, 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 19, 2008, at 9:48 PM, 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;">
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>

</blockquote>
<br></div>
In this example, I don't see where GetSVal() gets used other than handling the dereference of p, which will return the loc::MemRegionVal(region of a).  It seems like it just works (no special handling of array types </blockquote>
<div><br>This does not just work. We get loc::MemRegionVal(region of a) through special handling in GRExprEngine originally when we eval a's rvalue. And for the case of rvalue evaluation of *p, we will get UnknownVal in the original code.<br>
<br>Now as this patch does, we will get UnknownVal.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">required); VisitArraySubscriptExpr (with asLValue=true) will then call the store's VisitLValueElement with loc::MemRegionVal and nonloc::ConcreteInt respectively, returning an lvalue for the entire expression.  Since BasicStore doesn't reason about array accesses, (*p)[3] will evaluate to UnknownVal().<br>

</blockquote></div><br></div>