This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile semantics


> From: Jonathan Wakely <cow@compsoc.man.ac.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)

- 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]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]