[cfe-commits] [PATCH] RegionStore

[Zhongxing Xu]

Some more comments:

int a[10];
int (*p)[10];

Per C99 6.3.2p3, 'a' and '*p' is not lvalue when they are placed in a[1] or
(*p)[1]. So in fact we cannot do lvalue evaluation of them. But this is
inconsistent with the usual case in VisitDeclRefExpr and VisitUnaryExpr. But
'a' and '*p' do have lvalue sometimes. And special handling of these
non-lvalue cases in the GRExprEngine is ugly.

On the other hand, a simple trick in the Store will do us the favor. If we
are passed loc::MemRegionVal(some array's region) in the store, we do not go
through the binding, but simply return loc::MemRegionVal(some array's
region) as the loaded value. Then we can do the usual thing for all cases in
GRExprEngine's Visitors: get the lvalue of the Decl, ask Store what its
rvalue is.

On Mon, Oct 20, 2008 at 4:33 PM, Zhongxing Xu <xuzhongxing at gmail.com> wrote:

>
>
> On Mon, Oct 20, 2008 at 2:38 PM, Ted Kremenek <kremenek at apple.com> 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().
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081020/6804cc1d/attachment.html>