> From: Jonathan Wakely <[EMAIL PROTECTED]>
> 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)
- I don't contest that the side effect of such an assignment is undefined,
but do contest that an implementation has a right to arbitrarily modify
validly specified semantic actions (regardless of whether they are well
defined or not).
[but won't belabor the issue any further, as it's been discussed to death]
