[cfe-commits] [PATCH] RegionStore

Zhongxing Xu xuzhongxing at gmail.com
Mon Oct 20 07:15:10 PDT 2008


On Mon, Oct 20, 2008 at 2:06 PM, Ted Kremenek <kremenek at apple.com> wrote:

>
> On Oct 19, 2008, at 10:05 PM, Zhongxing Xu wrote:
>
>  As a more direct example, consider code
>>
>> int a[10];
>> a[1] = 3;
>>
>> 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.
>>
>
> Part of my confusion is that BasicStore doesn't model arrays.  We cannot
> expect to model array bindings using the simple VarDecl to SVal binding in
> BasicStore.  A "GetSVal" on a VarDecl with an array type should just return
> UnknownVal, since we don't have "element-sensitivity" in BasicStore.
>
> I think I see your point, but I'm not (completely) convinced it is the
> right approach to do this in the store, as it really seems to be an issue of
> syntax and performing the right conversions in GRExprEngine.  VisitLValue is
> called on "a[1]", and "Visit" is called on "a" (returning its rvalue).  The
> AST dump of the assignment looks like this:
>
>  (BinaryOperator 0xd07920 <line:3:3, col:10> 'int' '='
>    (ArraySubscriptExpr 0xd078e0 <col:3, col:6> 'int'
>      (ImplicitCastExpr 0xd078d0 <col:3> 'int *'
>        (DeclRefExpr 0xd07870 <col:3> 'int [10]' Var='a' 0xd07820))
>      (IntegerLiteral 0xd07890 <col:5> 'int' 1))
>    (IntegerLiteral 0xd07900 <col:10> 'int' 3)))
>
> Do you think it seems more reasonable for VisitCast to specially handle the
> case of casting an array type to a pointer?  One possible solution in this
> case would be to have VisitCast invoke VisitLValue on its subexpression when
> performing such a cast.  I'm not certain if this is the right thing to do.
>
>
After examining the code in CodeGen part of clang, now I think this approach
is also feasible. And it seems more reasonable to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081020/9333fbdb/attachment.html>


More information about the cfe-commits mailing list