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

[Zhongxing Xu]

Quotes from C++ standard:

>From 1.9 p13
        Evaluation of an expression (or a sub-expression) in general
includes both value computations (including determining the identity of an
object for lvalue evaluation and fetching a value previously assigned to an
object for rvalue evaluation) and initiation for side effect.

I think this indicates clearly we should separate the evaluation of an
expression into two steps: one for determine the lvalue of the expression
(then we get a location value), the other for fetch the value stored in that
location. And if we don't want the rvalue of the expression, we stop after
step one.

>From 3.10:
        Every expression is either an lvalue or an rvalue. An lvalue refers
to an object or function.

This is consistent with C. But what we should care about is that we have two
kinds of evaluations of expressions: lvalue evaluation and rvalue
evaluation. lvalue evaluation returns the address of the object that the
lvalue refers to. rvalue evaluation returns the value previously assigned to
the object. This indicates we should have:

AbstractVal GRExprEngine::VisitRValue(Expr* E)  (corresponds to the current
GRExprEngine::Visit())
and
LocVal GRExprEngine::VisitLValue(Expr*)      (corresponds to the
GRExprEngine::VisitLValue() in my patch)

VisitRValue returns an AbstractValue because an expression's rvalue can
either be location value or non-location value. And VisitLValue() always
returns location value (in practice it might also return UnknownVal or
UndefinedVal).

lvalue-to-rvalue conversion
I think this should not bother us too much. It only indicates that we should
do a rvalue-evaluation of the expression.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081012/0f00aa2e/attachment.html>