> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> | Paul Schlie <[EMAIL PROTECTED]> 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).
