Re: volatile semantics

[Geoffrey Keating <geoffk at geoffk dot org>]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

> 6.3.2.1:  when an object is said to have a particular type, the type is
> specified by the lvalue used to designate the object.  So the lvalue
> having a volatile-qualified type *means* that the object it designates has
> a volatile-qualified type; "has type X" and "is designated by an lvalue of
> type X" are synonymous (!).
> 
> 6.7.3:  any expression referring to an object of volatile-qualified
> type must be evaluated strictly by the rules of the abstract machine,
> although precisely what constitutes an "access" to the object is
> implementation-defined.  (Note, "implementation-defined" behavior is
> required to be well-defined and *documented*.)  So if the reference in
> question is an "access", it must occur where the abstract machine says
> it should.

I think you missed an important word here.  The standard actually
says, in 6.7.3 paragraph 6,

> An object that has volatile-qualified type may be modified in ways
> unknown to the implementation or have other unknown side
> effects. Therefore any expression referring to such an object shall be
> evaluated strictly according to the rules of the abstract machine

The word you missed is 'Therefore'.  If an implementation can
determine that an object is not modified unknown to the
implementation, the implementation need not evaluate it strictly
according to the rules of the abstract machine.

How could an implementation tell such a thing?  Well, the first
sentence is exclusive, it means that only volatile objects may be
modified unknown to the implementation.  If the user has declared

int i;

without 'volatile', then this object cannot be modified unknown to the
implementation, even if someone also writes '(*(volatile int *)&i) =
1'.