On Mon, Oct 20, 2008 at 2:38 PM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
> > On Oct 19, 2008, at 9:48 PM, Zhongxing Xu wrote: > > 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. >> > > 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 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. Now as this patch does, we will get UnknownVal. > 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(). >
regionstore3.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
