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

[Ted Kremenek]

On Oct 10, 2008, at 8:42 AM, Sebastian Redl wrote:

> 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.

I haven't had time to review Zhongxing's patch yet (sorry Zhongxing),  
but as far as "lval" and "nonlval" are concerned, I believe the  
situation is as follows:

LVal => lvalues (roughly)
NonLVal => rvalues (roughly)

My original confusion was that an rvalue was either an lvalue or  
something that wasn't an lvalue, where in reality the "something that  
wasn't an lvalue" is an rvalue (at least in parlance consistent with C+ 
+).

The other thing is that in the static analyzer we represent pointer  
values as lvals, so in the expression "*p" (if p is a pointer) the  
subexpression "p" evaluates to an object that subclasses LVal and and  
*p evaluates to the value stored at the given memory location (which  
in turn can be an LVal object if the returned value is also a  
pointer).  This is clearly inconsistent with the semantics you have  
outlined above, and it is giving me pause to think about how the  
current scheme should potentially be changed.  Making LVal and NonLVal  
(which should probably be called RVal) better reflect the use of these  
terms in the language specification not only will make things less  
confusing, but also make the implementation of the analyzer less prone  
to semantic mismatches of how the code should really be interpreted.