[llvm-commits] [llvm] r117070 - /llvm/trunk/lib/Analysis/TypeBasedAliasAnalysis.cpp

[Duncan Sands]

Hi John,

>>>   // If the third field is present, it's an integer which if equal to 1
>>> -// indicates that the type is "constant" (meaning
>>> -// pointsToConstantMemory should return true; see
>>> +// indicates that the type is "constant" (meaning pointsToConstantMemory
>>> +// should return true; see
>>>   // http://llvm.org/docs/AliasAnalysis.html#OtherItfs).
>>
>> is this "constant" field actually useful?  How are you imagining that it will
>> be used?  Even in Ada, which has a pretty strong type system and notions of
>> constantness, the fact that you have a view of an object via a constant type
>> doesn't mean that the object can't be altered, it just means it can't be
>> altered via this view.  In C, this is something like saying: suppose the
>> address of an int is held in a "const int*", then you can't alter the int via
>> this pointer; but you can always alter it by putting the address of the int in
>> a "int *" and using that instead.  So the fact that you have a "const int*"
>> doesn't mean you that it is valid for pointsToConstantMemory to return true.
>
> Both C and C++ say that modifying an object defined with a const qualifier
> has undefined results, so while you can't use this for pointer-to-const, you
> could use it for const variables after they've been initialized.

in the case of a cont variable, is the constness part of the type?

Ciao,

Duncan.