Re: volatile semantics

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote:

> > Note that I'm explicitly not taking a position on what the standard says.
> > The standard is notoriously incomplete with respect to object model issues,
> > including volatility, so I think that trying particularly hard to parse its
> > words in this area is probably not a good use of time for people trying to
> > build a real-world compiler. Creating DRs is more useful than trying to read
> > the tea leaves.
> >
> > Clearly, the analogous rule does not make sense for "const" in that a "const"
> > object can never be modified; in particular, if the compiler can prove that
> > "*x = 3" is an attempt to modify an object whose dynamic type is "const int",
> > then it can replace that with a call to "kill (SIGSEGV)", if it likes; this
> > is unquestionably undefined behavior.
> 
> With all due respect, unless there is an explicit reference in the standard
> to contradict it's clearly stated requirement that an object's qualified
> lvalue ("locator value") designates the object being referenced, all
> interpretations to the contrary are at best presumptuous, regardless of
> whether or not it's generalized behavior may be indeterminate.

Does the first sentence of the following text count?

  6.7.3  Type qualifiers

       [#5] 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.   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 behavior is undefined.113)

jon