On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:
Geoffrey Keating <[EMAIL PROTECTED]> writes:Although I can see that this is how you might think about the semantics of 'const' and 'volatile', I don't think they're an exact match for the model in the standard. In fact, I think you could exchange the words 'const' and 'volatile' in the above and they would be equally accurate.Sure, and I think my ultimate point would still be accurate: gcc should handle the access using the qualification of the pointer, not of the underlying object. The rest of the argument is just motivation.
By "equally accurate", I also meant "equally inaccurate".You've successfully argued that 'const' and 'volatile' are the same in lots of ways; but 'const' and 'volatile' do differ. In order to be successful in this argument, you need to argue that the differences don't matter.
And, unfortunately, the differences *do* matter. The standard does not say "any expression referring to a volatile-qualified type must be evaluated strictly according to the rules of the abstract machine". What it says is that "An object that has volatile qualified type may be modified in ways unknown to the implementation" and then lists some of the consequences of an object being modifiable in that way. So there are no "semantics of the access"; the semantics attach to the object.
This is part of what I meant by saying that your model isn't a match for the model in the standard. Your model had semantics attached to the access.
In fact const and volatile are analogous here. If you have a non-const object, and you attempt to access it with a const-qualified pointer, the compiler will apply the semantics of const (i.e., it will reject an attempt to modify the object through the pointer).
There are no general differences in semantics of a 'const' access. There are only special semantics of an assignment to a 'const' lvalue (it's not allowed). Nor are there any special semantics of a 'const' object; in particular, it is not true that a 'const' object cannot change, only that it can't be changed from C. So it's not true that const and volatile are analogous here, nor is it true that an access to a non-const object with a const-qualified pointer is different to accessing it with a non-const-qualified pointer.
I am discussing here only with what GCC *could* do, and still be standards-conforming. What it *should* do is a different conversation.
smime.p7s
Description: S/MIME cryptographic signature
