«

On Dec 30, 8:07 pm, Keith Thompson <ks...@mib.org> wrote:
> Here's what the standard says (C99 6.7.3p6):
>
> 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, as described in 5.1.2.3. Furthermore,
> at every sequence point the value last stored in the object
> shall agree with that prescribed by the abstract machine, except
> as modified by the unknown factors mentioned previously. What
> constitutes an access to an object that has volatile-qualified
> type is implementation-defined.
>
> with a footnote:
>
> A volatile declaration may be used to describe an object
> corresponding to a memory-mapped input/output port or an object
> accessed by an asynchronously interrupting function. Actions
> on objects so declared shall not be ‘‘optimized out’’
> by an implementation or reordered except as permitted by the
> rules for evaluating expressions.
>
> On the other hand, if you just apply "volatile" to a local variable,
> the compiler can reasonably know that there's no magic going on behind
> the scenes. It's not clear whether the compiler is permitted to take
> advantage of this knowledge; I'd say it probably isn't.

OK but is that footnote normative? I would be surprised if so.

It does appear that this is a gray area in the standard that needs
clarifying.

My suggestion would be to change the semantics of volatile for a local
(automatic) variable, to mean that accesses to the variable would be
guaranteed atomic (so the compiler would automatically insert a mutex to
protect accesses, if the variable's type cannot be accessed atomically on
the host architecture). Assuming that the C standard follows the next C++
standard in including multithreading support, this issue will have to be
addressed anyway, and using the already existing volatile keyword seems
to take care of this very neatly.

My $0.02...

Simon P Simonson <> writes:
> On Dec 30, 8:07 pm, Keith Thompson <ks...@mib.org> wrote:
>> Here's what the standard says (C99 6.7.3p6):
>>
>> 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, as described in 5.1.2.3. Furthermore,
>> at every sequence point the value last stored in the object
>> shall agree with that prescribed by the abstract machine, except
>> as modified by the unknown factors mentioned previously. What
>> constitutes an access to an object that has volatile-qualified
>> type is implementation-defined.
>>
>> with a footnote:
>>
>> A volatile declaration may be used to describe an object
>> corresponding to a memory-mapped input/output port or an object
>> accessed by an asynchronously interrupting function. Actions
>> on objects so declared shall not be ‘‘optimized out’’
>> by an implementation or reordered except as permitted by the
>> rules for evaluating expressions.
>>
>> On the other hand, if you just apply "volatile" to a local variable,
>> the compiler can reasonably know that there's no magic going on behind
>> the scenes. It's not clear whether the compiler is permitted to take
>> advantage of this knowledge; I'd say it probably isn't.
>
> OK but is that footnote normative? I would be surprised if so.
[snip]

Footnotes are never normative. In theory, they just provide
clarification of information that's already stated in the normative
text. In practice, the standard is an imperfect document written by
imperfect humans, and things don't always work out correctly. I'm
particularly disturbed by the use of "shall" in this footnote.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"