From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1276 invoked by alias); 23 Jul 2005 02:15:23 -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 1268 invoked by uid 22791); 23 Jul 2005 02:15:19 -0000 Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 23 Jul 2005 02:15:19 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc13) with SMTP id <20050723021512013008qhjke>; Sat, 23 Jul 2005 02:15:17 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 23 Jul 2005 02:15:00 -0000 Subject: Re: volatile semantics From: Paul Schlie To: Geoffrey Keating CC: "D. Hugh Redelmeier" , Nathan Sidwell , Dale Johannesen , Mike Stump , GCC Development Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-07/txt/msg00974.txt.bz2 > Geoffrey Keating writes: > > int i; - merely means: allocate and treat all references to the object as referencing an unqualified int object, unless re-qualified within a more local scope. > without 'volatile', then this object cannot be modified unknown to the > implementation, even if someone also writes '(*(volatile int *)&i) = 1'. - merely means: treat the object being referenced as volatile qualified int object (as the standard specifies, although it may result in an undefined behavior, nothing more or less; as although the object may have not been initially declared as being volatile, the program within the context of this particular references has asserted that it must be treated as such, thereby implying it's value must be assigned, and/or presumed to have been possibly modified beyond the logical view of the program). const, volatile, and restrict are all logically equivalent in this regard; regardless of whether or not an object was declared as being originally qualified, or subsequently declared as being so within the more restricted scope of a function via it's parameter declaration, or single reference via a qualified cast. Where although inconsistent references to any single object may result in an undefined behavior, it should be clear there's no value in attempting to rationalize any more creative less consistent interpretation, as it will be no more correct, and only likely unnecessarily complicating to both the implementation and programmer.