From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24533 invoked by alias); 22 Jul 2005 23:20:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24329 invoked by uid 22791); 22 Jul 2005 23:20:44 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 22 Jul 2005 23:20:44 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j6MNKgiW022805 for ; Fri, 22 Jul 2005 16:20:42 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 22 Jul 2005 16:20:40 -0700 Received: from greed.local (vpn2priv-96.apple.com [17.219.204.96]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j6MNKXfX011759; Fri, 22 Jul 2005 16:20:34 -0700 (PDT) Received: by greed.local (Postfix, from userid 501) id 7904657C819; Sun, 17 Jul 2005 12:26:34 -0700 (PDT) To: Ian Lance Taylor Cc: Andrew Haley , "D. Hugh Redelmeier" , gcc@gcc.gnu.org, Nathan Sidwell , Dale Johannesen , Mike Stump Subject: Re: volatile semantics References: <851D2CB0-93DF-4C49-A6A8-8895DB1A08F9@apple.com> <42778D99.7070904@codesourcery.com> <17113.17689.558864.411876@zapata.pink> <1121536373.29893.10.camel@linux.site> From: Geoffrey Keating Date: Fri, 22 Jul 2005 23:20:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2005-07/txt/msg00968.txt.bz2 Ian Lance Taylor writes: > Daniel Berlin writes: > > > > In other words, we're asked to agree that the type of an object > > > changes depending on how it is accessed. > > > For the benefit of readers, only the first sentence of this para is > > > the language of the standard; the rest isn't. > > > > > > That an object referred to through a volatile pointer must > > > "temporarily" be treated as though it were declared volatile is the > > > crux of this argument. > > > > Again, you could say the same about const, restrict, or any other > > qualifier then, making them more or less useless as qualifiers. > > I think there may be a difference. > > const is inherently a characteristic of the object. It applies at > definition time. Casting away const in a reference does not change > the definition. Whether making an assignment through a pointer after > casting away const is legal depends upon how the definition of the > object pointed to is handled (C99 6.7.3: "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"). The very next sentence says > 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 behaviour is undefined. so I don't see how this supports your distinction between 'const' and 'volatile'. > volatile, on the other hand, is inherently a characteristic of the > access, not of the object. Defining a volatile object does nothing in > itself; it merely affects all accesses to the object. Thus casting to > volatile should mean that all uses of the resulting pointer should be > done in a volatile fashion--i.e., all reads and writes done precisely > as specified by the standard's "abstract machine." Casting away from > volatile means the reverse--there are no restrictions on the use of > the object to which the pointer points. Although I can see that this is how you might think about the semantics of 'const' and 'volatile', I don't think they're an exact match for the model in the standard. In fact, I think you could exchange the words 'const' and 'volatile' in the above and they would be equally accurate. The above reminds me of the arguments in physics about the wave or particle nature of things. The answer, of course, is that although those are useful models, neither is an exact description of all the properties.