[cfe-commits] [PATCH] Expressions have lvalues and rvalues

[Sebastian Redl]

Zhongxing Xu wrote:
> In static analysis, when an expression is on the LHS of an assignment 
> statement, we want to get the storage location it represents, I 
> call it lvalue of the expression. When an expression is on the RHS of 
> an assignment statement, we want to get its value in the normal sense, 
> I call it the rvalue of the expression. If such terminology should 
> cause confusion, I am OK to change the terminology.
No, this terminology is perfectly consistent with what I've learned.
> Talking about the abstract values occuring in the static analysis, we 
> divide them into two categories: LVal and NonLVal. LVal represents 
> some kind of abstract location value, that is some address. NonLVal 
> represent non-location value.
This is the part that confuses me. What's the difference between an lval 
and an lvalue, between a nonlval and an rvalue? The similarity between 
lval and lvalue is one of my main problems with this terminology.
> So an expression's lvalue must be LVal, while its rvalue might be 
> either LVal or NonLVal.
That doesn't sound logical. Since the rvalue is the "actual" value, it 
cannot be locational. Unless it's a pointer, but that's a very special case.
> The terminologies used here are not intended to be strictly consistent 
> with the C/C++ standard. Because we are not doing codegen, but doing 
> static analysis - symbolically simulating the execution of the program.

In the view of the C++ standard, an expression yields a value. This 
value can be an rvalue or an lvalue. Dereferencing of pointers, direct 
variable references, and any expression that yields a reference (lvalue 
reference, that is) are expressions that yield lvalues. All other 
expressions yield rvalues.
Supply an lvalue to an expression expecting an rvalue (such as 
addition), and the standard lvalue-to-rvalue conversion is performed. 
For most types, this is a no-op, an abstract change of viewpoint (it's 
no longer the location, now it's the actual value). On the assembly 
level, it might be a memory fetch. For arrays, it's the array decay, for 
functions, it's the implicit conversion to a function pointer.
Supply an rvalue to an expression expecting an lvalue, you get an error 
in most cases. Binding to a const reference is one exception, calling 
member functions of a temporary object the other.

I just don't see where lval and nonlval have any place in this, and I 
see a huge potential for confusion in introducing these names.

Sebastian