From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28600 invoked by alias); 17 Jul 2005 08:25:35 -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 28585 invoked by uid 22791); 17 Jul 2005 08:25:30 -0000 Received: from yosemite.airs.com (HELO yosemite.airs.com) (205.217.158.180) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Sun, 17 Jul 2005 08:25:30 +0000 Received: (qmail 22365 invoked by uid 10); 17 Jul 2005 08:25:28 -0000 Received: (qmail 26467 invoked by uid 500); 17 Jul 2005 08:25:20 -0000 To: Daniel Berlin 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: Ian Lance Taylor Date: Sun, 17 Jul 2005 08:25:00 -0000 In-Reply-To: <1121536373.29893.10.camel@linux.site> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-07/txt/msg00714.txt.bz2 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"). restrict is less interesting, since it simply provides a guarantee about a pointer. Casting away restrict does nothing useful--it just abandons the guarantee. Casting to restrict is by definition only valid if the guarantee holds--if the object is indeed restricted (C99 6.7.3.1: ".... If these requirements are not met, then the behavior is undefined"). 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. I am not aware of any other type qualifiers in C or C++. Ian