On Wed, Oct 15, 2008 at 3:34 PM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
> > On Oct 12, 2008, at 4:26 AM, Zhongxing Xu wrote: > > 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). >> > > Yep, this is exactly what we do now. I don't know if renaming Visit to > VisitRValue is worth it. Probably would make the code far more > self-documenting. I prefer not to rename. Just having Visit and VisitLValue seems clear enough. > > > 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. >> > > Agreed. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
