Yeah, it seems a little confusing. But other names are worse:
AbstractVal, too long
AVal, like nonsense.
ProgVal, even farther way.
If ExprVal has to be replaced, I prefer AVal, at least it indicates some
special value: AVal.
On Fri, Oct 17, 2008 at 1:22 PM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
>
> On Oct 16, 2008, at 10:15 PM, Zhongxing Xu wrote:
>
> This is the renaming patch:
>>
>> RVal => ExprVal
>> LVal => Loc
>> NonLVal => NonLoc
>> lval => loc
>> nonlval => nonloc
>> <rename.patch>_______________________________________________
>>
>
> The patch looks great, but I'm a little hesitant about the name "ExprVal."
> For example, this patch shows "ExprVals" being used with the Store:
>
> +Store BasicStoreManager::SetExprVal(Store store, Loc LV, ExprVal V) {
> switch (LV.getSubKind()) {
> - case lval::MemRegionKind: {
> + case loc::MemRegionKind: {
> VarRegion* R =
> - dyn_cast<VarRegion>(cast<lval::MemRegionVal>(LV).getRegion());
> + dyn_cast<VarRegion>(cast<loc::MemRegionVal>(LV).getRegion());
>
> if (!R)
> return store;
> @@ -157,16 +157,16 @@
> : VBFactory.Add(B, R->getDecl(), V).getRoot();
> }
> default:
> - assert ("SetRVal for given LVal type not yet implemented.");
> + assert ("SetExprVal for given Loc type not yet implemented.");
> return store;
> }
> }
>
> This just seems confusing. Why is the store reasoning about "expression
> values"? It makes sense to those using the system already, but the name
> doesn't capture its purpose well.
>
> What do you think? AbstractVal? AVal? ProgVal?
>
> Otherwise I think the patch looks great. Changing ExprVal to something
> else is just a couple lines of Perl/sed.
>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
