From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29771 invoked by alias); 18 Jun 2008 03:52:15 -0000 Received: (qmail 29623 invoked by uid 22791); 18 Jun 2008 03:52:13 -0000 X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Jun 2008 03:51:32 +0000 Received: from mail.gnu.org ([199.232.76.166]:49810 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1K8off-0001io-Kk for gcc@gnu.org; Tue, 17 Jun 2008 23:49:19 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1K8ohi-0006DP-PN for gcc@gnu.org; Tue, 17 Jun 2008 23:51:29 -0400 Received: from synapse.neuralscape.com ([198.144.200.82]:35135 helo=neuralscape.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K8ohi-0006D1-8E for gcc@gnu.org; Tue, 17 Jun 2008 23:51:26 -0400 Received: from localhost.neuralscape.com ([127.0.0.1] helo=synapse.neuralscape.com) by neuralscape.com with esmtp (Exim 4.42) id 1K8ohg-0007AJ-V0; Tue, 17 Jun 2008 20:51:25 -0700 Received: (from shaeffer@localhost) by synapse.neuralscape.com (8.13.8/8.13.8/Submit) id m5I3pOmW027546; Tue, 17 Jun 2008 20:51:24 -0700 Date: Wed, 18 Jun 2008 03:52:00 -0000 From: Karen Shaeffer To: Andrew Pinski Cc: Ian Lance Taylor , gcc@gnu.org Subject: Re: auto const ints and pointer issue Message-ID: <20080618035124.GA27477@synapse.neuralscape.com> References: <20080617174222.GA19409@synapse.neuralscape.com> <20080618014401.GA25773@synapse.neuralscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg00382.txt.bz2 On Tue, Jun 17, 2008 at 09:52:17PM -0400, Andrew Pinski wrote: > On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer > wrote: > > On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote: > >> > ~~~~~~~~~~~~~~~~ output ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > $ const_ints > >> > const int ic = 0 *cip = 5 *ip = 5 > >> > &ic = 0xbfbd72a0 cip = 0xbfbd72a0 ip = 0xbfbd72a0 > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> > In my opinion, it seems reasonable to limit the undefined > > behavior to the value of the variable, or to some form of > > failure and error, up to and including crashing the process. > > But to implement the code in such a way to let the process > > proceed without error, and to have incorrect addresses as we > > see here, seems to be beyond the common sense scope of the bounds > > of what this assignment's undefined behavior potential effects > > might be. It is interesting. Thank you for your comment. > > I don't see the issue with the pointers being the same. I don't see > what you are asking to be different. Casting from one pointer type to > another is ok. So we can go from: > cip = ⁣ > ip = (int *)cip; > cip = ip; > > And cip should be the same as &ic at the end of that code sequence. > > Thanks, > Andrew Pinski Hi Andrew, I see your point. My sticking point is that the process is actually running on a physical machine. And the addresses, although virtual, do translate to a unique physical memory location. And, the value stored in that location cannot be 0 and 5 at the same time. And my comments were addressing that the undefined behavior of this illegal assignment should not violate the physical constraints of what is actually stored in that physical address. I would be OK with -1 being stored in there, or zero, or whatever, or the process crashing, but what I see is not congruent with my thinking about the limits of the compiled binary at run-time. Obviously I need to rethink those assumptions. Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 shaeffer@neuralscape.com http://www.neuralscape.com