[cfe-commits] [PATCH] Expressions have lvalues and rvalues

[Ted Kremenek]

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.

Ok.

>
>
>
> 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.

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  
lval/nonlval nomenclature.

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.