Geoffrey Keating <[EMAIL PROTECTED]> writes: > > const is inherently a characteristic of the object. It applies at > > definition time. Casting away const in a reference does not change > > the definition. Whether making an assignment through a pointer after > > casting away const is legal depends upon how the definition of the > > object pointed to is handled (C99 6.7.3: "If an attempt is made to > > modify an object defined with a const-qualified type through use of an > > lvalue with non-const-qualified type, the behavior is undefined"). > > The very next sentence says > > > If an attempt is made to refer to an object defined with a > > volatile-qualified type through use of an lvalue with > > non-volatile-qualified type, the behaviour is undefined. > > so I don't see how this supports your distinction between 'const' and > 'volatile'.
I know that sentence is there, but it's irrelevant to the point I was trying to make. In the paragraph quoted above I was discussing objects defined as const. The issue at hand is about an object which is not defined as volatile, for which an access is made using a volatile qualified pointer. 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). Similarly, I am arguing that if you have a non-volatile object, and you attempt to access it with a volatile-qualified pointer, the compiler should apply the semantics of volatile. > > volatile, on the other hand, is inherently a characteristic of the > > access, not of the object. Defining a volatile object does nothing in > > itself; it merely affects all accesses to the object. Thus casting to > > volatile should mean that all uses of the resulting pointer should be > > done in a volatile fashion--i.e., all reads and writes done precisely > > as specified by the standard's "abstract machine." Casting away from > > volatile means the reverse--there are no restrictions on the use of > > the object to which the pointer points. > > 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. > The above reminds me of the arguments in physics about the wave or > particle nature of things. The answer, of course, is that although > those are useful models, neither is an exact description of all the > properties. The key difference, of course, is that the C language was made up by humans, and thus to a specific question like this (how should we handle an access through a volatile-qualified pointer) there either is an answer already, or we can make one up. It is not unknowable or ambiguous or subject to future research, although the answer may be "the compiler can do as it pleases." Ian
