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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
