Hi Zhongxing, This is an interesting patch. I'm going to scrutinize it so that I understand its full ramifications (both in terms of design and functionality), so I might not get back to you immediately.
Ted On Oct 9, 2008, at 6:45 AM, Zhongxing Xu wrote: > This patch introduces VisitLValue() to evaluate the lvalue of an > expression. VisitLValue() > is different from VisitLVal(). The motivation of this patch is as > follows. > > We have two kinds of RVal: LVal and NonLVal. LVal represents > location value, > NonLVal represents non-location value. > > Expressions have two kinds of value: rvalue and lvalue. The rvalue > of an > expression is is the normal value it evaluates to when placed at the > RHS of an > assignment. The lvalue of an expression is the address of the memory > object it > represents. > > We should distinguish rvalue/lvalue from NonLVal/LVal. An > expression's lvalue > must be a LVal. An expression's rvalue can be either NonLVal or > LVal. Every > expressoin has its rvalue. But not all of the expressions have > lvalues. For > example: > > int x = 3; > > "3" has rvalue 3, but no lvalue > "x" has rvalue 3, lvalue is its associated memregion MemRegionVal > "&x" has no lvalue, but has rvalue, which is the lvalue of 'x', i.e. > MemRegionVal of x > > So I suggest when we evaluate expressions, we pass on an argument > indicating > whether we want to get its lvalue/rvalue, instead of specifying we > are getting a > LVal or NonLVal. > > In this patch, I use LValue/RValue to distinguish from LVal/NonLVal. > > This patch cleans up a bunch of code. It lets store manager to > evaluate the lvalue > of an expression. > <lvalue.patch>_______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
