From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30056 invoked by alias); 3 Jan 2005 06:57:20 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 29989 invoked from network); 3 Jan 2005 06:57:09 -0000 Received: from unknown (HELO redpinesignals.com) (203.196.161.92) by sourceware.org with SMTP; 3 Jan 2005 06:57:09 -0000 Received: from [192.168.1.11] ([192.168.1.11]) by redpinesignals.com (8.12.10+Sun/8.12.5) with ESMTP id j037Jbik005598 for ; Mon, 3 Jan 2005 12:49:38 +0530 (IST) Message-ID: <41D8ED78.1030101@redpinesignals.com> Date: Mon, 03 Jan 2005 06:57:00 -0000 From: Sriharsha Organization: Redpine Signals Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: assigning to const int via pointer References: <87652k5lcy.fsf@proxy.tcenet> <41D4F5F9.9000404@redpinesignals.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00006.txt.bz2 Got it now. Thank you. Ian Lance Taylor wrote: >Sriharsha writes: > > > >>>>The following code assigns a value to a `const int` via a >>>>pointer., >>>> >>>>#include >>>> >>>>int main() >>>>{ >>>> const int x=5; >>>> int *ptr; >>>> ptr = &x; >>>> *ptr = 10; >>>> printf("%d",x); >>>>} >>>> >>>>The code gives `10` for the following compilation >>>> >>>> $gcc -o test test.c >>>> >>>>It gives `5` when using optimisations switches., >>>> >>>> $gcc -o test -O2 test.c >>>> >>>>Feature or bug or any explanation for this? >>>> >>>> >>>When you declare that the variable is const, you are declaring that >>>the value does not change. When you do change it, you are using >>>undefined behaviour. When the compiler sees undefined behaviour, it >>>does not behave predictably. >>> >>>ISO 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." >>> >>> >>> >>I am a little confused. >> >> > >Yes. > > > >>The rule says: >>If an attempt is made to modify an object, defined with a >>const-qualified type, through use of an lvalue with a >>non-const-qualified type, the behavior is undefined. >> >>Now, in the above, program, we are not trying to alter the value of >>the variable x as follows: >>x = 10; >> >>But we are trying to alter the contents of a memory location, which >>happens to be where the variable 'x' refers to, by using a pointer, >>which is defined behaviour. >> >> > >No. Note that the rule is about modifying "an object". The object in >question was defined by the definition of 'x', and thus was defined >using a const-qualified type. The assignment through 'ptr' is >modifying an object defined with a const-qualified type. > > > >>According to the rule, you cannot use the variable, declared as a >>const-qualified type, on the left hand side (lvalue, or assigned-to >>variable), but it does not say anything about the memory being >>modified. >> >> > >No. The rule I quoted doesn't say that you can't use a >const-qualified type as an lvalue. It says that you can't use an >lvalue with a non-const-qualified type to modify an object defined >with a const-qualified type. *ptr is an lvalue with a >non-const-qualified type. It is being used to modify the object >defined by the declaration of x with a const-qualified type. > > > >>Please correct me if I am wrong. Also, when you qualify the type of x >>to be a volatile, then the behaviour is as expected. So, there must be >>some other reason why the variable "int *ptr" is being discarded by >>Optimization. Check out that without optimization, you are able to >>change the contents. Also, I've tried this with a few other compilers >>(without optimization) and they all change the contents. >> >> > >The program performs undefined behaviour. Therefore the compiled >results are unpredictable. It is not surprising that the behaviour is >different among different compilers and different optimization levels. > >Ian > > > -- ***************************** * Sriharsha Vedurmudi * Software Engineer * * Redpine Signals Inc. * Gate #395, Plot 87,88 * Sagar Society, Road #2, * Banjara Hills, * Hyderabad - 500 034 * www.redpinesignals.com * * +91-40-23559911 (Office) * +91-98851-37338 (Mobile) *****************************