> 1) Change "RVal" to "ExprVal" (representing the value of an expression). > ExprVal makes it clear that these objects represent the evaluation of an > expression. >
I am fine with "ExprVal". "AbstractVal" more faithfully reflects what it is. But it is a little long. > > 2) Change 'nonlval::" to "rval::", and remove most of the lval classes such > as lval::SymbolicInt and lval::ConcreteInt. Add an "rval::MemoryRegion" > class that mirrors "lval::MemoryRegion". > I think here we are differentiating values describing abstract memory location from values describing abstract mathematical value. So I prefer "locval::" and "nonlocval::". Again, they are a little long. > > 3) Change GRExprEngine to reason about rvals (rvalues) and lvals (lvalues) > in the same way the C++ standard does. This is a big task, but I think it > is mainly code restructuring. > Are the current Visit() and VisitLValue() appropriate, the former for rvalue evaluation, the latter for lvalue evaluatioin? > Loads would be handled as transfer functions (i.e., EvalLoad) doing the > implicit conversions between lvals -> rvals. > Conversion between lvalue -> rvalue? With the help of Store?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
