volatile semantics

[Geoff Keating]

On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:

> Geoffrey Keating <geoffk@geoffk.org> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050723/560522ea/attachment.p7s>