<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div>1) Change "RVal" to "ExprVal" (representing the value of an expression).  ExprVal makes it clear that these objects represent the evaluation of an expression.</div>
</div></blockquote><div><br>I am fine with "ExprVal". "AbstractVal" more faithfully reflects what it is. But it is a little long.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div></div><div><br></div><div>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".</div>
</div></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div><br></div><div>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.  </div>
</div></blockquote><div><br>Are the current Visit() and VisitLValue() appropriate, the former for rvalue evaluation, the latter for lvalue evaluatioin?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div>Loads would be handled as transfer functions (i.e., EvalLoad) doing the implicit conversions between lvals -> rvals.</div></div></blockquote><div> </div><div>Conversion between lvalue -> rvalue? With the help of Store?<br>
<br></div></div></div>