[cfe-commits] [PATCH] Expressions have lvalues and rvalues
kremenek at apple.com
Wed Oct 15 00:32:38 PDT 2008
On Oct 12, 2008, at 6:34 PM, Zhongxing Xu wrote:
> 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
Yes. I agree with you 100% now on this. locval and nonlocval are
great, since they represent an abstract mathematical value. This is
originally the design I intended, but I confused the issue with the
As a shorter name, what about "loc" and "nonloc"? They all subclass
ExprVal. On second though, AbsVal (short for AbstractVal) is probably
fine too, and shorter.
> 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?
I think so.
> 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?
Yes, this is what we do now, and it works just fine. It allows the
analyzer to reason about mathematical values, and have the lvalue/
rvalue reasoning (which reflects the language syntax) be handled as we
walk the expression tree.
More information about the cfe-commits