Re: volatile semantics

[Paul Schlie <schlie at comcast dot net>]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> | Paul Schlie <schlie@comcast.net> writes:
> | > 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.
> | 
> | (but regardless, at least things are successively approximating "correct")
> 
> I don't understand what you mean here.  Are you seriously suggesting
> that 
> 
>      int main(void) {
>         const int x = 4;
>         *(int*)&x = 3;
>      }
> 
> is well-defined?

Actually yes, I believe it's well defined that:

- The assignment reference to x is valid as it's not specified as const,
  therefore must be performed, unless:

- It is KNOWN at the time of compilation that an absents of it's side effect
  would have no logical consequential effect (as might be the case for
  example if a write to a ROM allocated object were silently physically
  ignored, but not for example if a write were specified to a RAM allocated
  object), however:

- As allocation side effects may differ for different targets and/or
  implementations, the behavioral consequence of the correctly specified and
  valid assignment to a const declared object may also correspondingly
  differ; so therefore although valid, the effect of the assignment is not
  itself warranted to be portable (but that it will logically occur is).