From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32652 invoked by alias); 18 Jun 2008 12:53:48 -0000 Received: (qmail 32635 invoked by uid 22791); 18 Jun 2008 12:53:47 -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 12:53:19 +0000 Received: from mail.gnu.org ([199.232.76.166]:42528 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1K8x7y-0003gy-FG for gcc@gnu.org; Wed, 18 Jun 2008 08:51:06 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1K8xA1-0001ZJ-NN for gcc@gnu.org; Wed, 18 Jun 2008 08:53:17 -0400 Received: from mail.gmx.net ([213.165.64.20]:41524) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1K8xA1-0001YB-4d for gcc@gnu.org; Wed, 18 Jun 2008 08:53:13 -0400 Received: (qmail invoked by alias); 18 Jun 2008 12:53:10 -0000 Received: from 98-62.78-83.cust.bluewin.ch (EHLO [192.168.123.202]) [83.78.62.98] by mail.gmx.net (mp047) with SMTP; 18 Jun 2008 14:53:10 +0200 X-Authenticated: #14737133 Message-ID: <48590530.3060405@gmx.ch> Date: Wed, 18 Jun 2008 12:53:00 -0000 From: jlh User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Karen Shaeffer CC: gcc@gnu.org Subject: Re: auto const ints and pointer issue References: <20080617174222.GA19409@synapse.neuralscape.com> <20080618014401.GA25773@synapse.neuralscape.com> <20080618035124.GA27477@synapse.neuralscape.com> In-Reply-To: <20080618035124.GA27477@synapse.neuralscape.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-IsSubscribed: yes 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/msg00391.txt.bz2 Hi! Karen Shaeffer wrote: > 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. Correct, and there aren't two values in that physical memory location, there is only one value stored in there: the value 5. (Assuming GCC 4.1.2 with -O2.) At the time where the first printf() is executed, the program won't even bother to go read that memory location (which contains the value 5), because it *knows* that it contains the value 0. It knows it because you promised that it contains the value 0 and that it will never ever change. So it won't even bother loading it and directly print the value 0. That's the result of an optimization: Not reading a memory location when its content is already known makes your program run faster; just use the known content instead. But you as the programmer have given GCC a promise that you broke later on and thus the program behaves in an arguably unexpected way. (It *is* expected, since printing what it prints falls under the definition of "undefined behavior.) In fact, that memory location is never actually read. When printing *cip and *ip, the program simply prints 5, because it knows there's the value 5 in that memory location, because it just wrote it there. Even the "ci = 0" is not storing to any memory location, it has been optimized away. All that remains is a useless assignment of the value 5 into a memory location that is never read again, and the resulting code: printf("const int ic = %d *cip = %d *ip = %d\n", 0, 5, 5); However, if I compile with -O0 (no optimization), then the program prints what you might have expected. "Undefined behavior" means for you: Avoid it and don't expect the compiler to try to do any sane thing when encountered or to reduce damage to a minimum or to do the "expected" thing. That would even be impossible to do. Just don't be undefined and you're fine. Oh, and looking at the assembly output (with "gcc file.c -S") is often very helpful to see what's going on. Hope this helps, jlh