<div dir="ltr">Quotes from C++ standard:<br><br>From 1.9 p13<br>        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.<br>
<br>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.<br>
<br>From 3.10:<br>        Every expression is either an lvalue or an rvalue. An lvalue refers to an object or function.<br><br>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:<br>
<br>AbstractVal GRExprEngine::VisitRValue(Expr* E)  (corresponds to the current GRExprEngine::Visit())<br>and <br>LocVal GRExprEngine::VisitLValue(Expr*)      (corresponds to the GRExprEngine::VisitLValue() in my patch)<br>
<br>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).<br>
<br>lvalue-to-rvalue conversion<br>I think this should not bother us too much. It only indicates that we should do a rvalue-evaluation of the expression.<br><br><br></div>