Hi All,

     I have the following question asked by my friend.

/*Copiled using C++ compiler*/
#include <stdio.h>

int main()
{
 const int i = 10;
 int *p = (int *)&i;
 ++(*p);
 printf("%d\n",i);
 printf("%d\n",*p);
 return 0;
}

The output is
10
11

/*Copiled using C compiler*/
#include <stdio.h>

int main()
{
 const int i = 10;
 int *p = (int *)&i;
 ++(*p);
 printf("%d\n",i);
 printf("%d\n",*p);
 return 0;
}

The output is
11
11

We tried this in VC++ 6.0, gcc and solaris native compiler. All the
compilers give the same answer. My friend says it is the expected
behaviour of the languages. Is it the standard behaviour of the
languages? Can anyone please explain? I don't have any clue about
this?

Regards,
Mohan.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mohanasundaram wrote:
> My friend says it is the expected
> behaviour of the languages.

No, your program invokes undefined behavior.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 7 Mar 2004 20:52:16 +0000 (UTC), DAGwyn@null.net ("Douglas A.
Gwyn") wrote in comp.std.c:

> Mohanasundaram wrote:
> > My friend says it is the expected
> > behaviour of the languages.
>
> No, your program invokes undefined behavior.

...in both languages.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

mohanasundaram@msn.com (Mohanasundaram) wrote in message news:<9bb9619e.0403040142.28b9da4b@posting.google.com>...
> Hi All,
>
>      I have the following question asked by my friend.
>
> /*Copiled using C++ compiler*/
> #include <stdio.h>
>
> int main()
> {
>  const int i = 10;
>  int *p = (int *)&i;
>  ++(*p);
>  printf("%d\n",i);
>  printf("%d\n",*p);
>  return 0;
> }
>
> The output is
> 10
> 11
>

Others already pointed out: it is undefined behaviour. So the compiler
may create anything including code that formats your harddisk. OTOH
compilers contain some logical behaviour so the compiler will probably
not create such exotic code;-).

A (guessed) explanation for the output you see:

First you told the compiler that i is constant with value 10. therefor
the compiler may substitute every use of i with 10. This explains the
first printf statement.
With the definition of int* p the need for an adress of i arises. So
the compiler will put i into memory (initialized with 10) and give
it's address to p.
The static cast is a lie, but the compiler assumes you know what you
do (do you?) and keeps quiet. The increment may fail if the compiler
puts i into some write protected memory - then you get at least a
runtime exception.
If the increment doesn't fail (write protected memory is perhaps not
available in the given architecture) the output of the second printf
then shows the expected result.

> /*Copiled using C compiler*/
[...]
>
> The output is
> 11
> 11
>
[...]

I don't know why the compiler doesn't substitute i with the value 10
here but I guess its for compatibility reasons that a constant integer
gets some place in memory which will be referred to on access.

But I repeat it's undefined behaviour and anything else may happen
too.

Friedhelm.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi All,

     Can you please tell me which statement causes that undefined
behaviour. The above posts say that the program invokes undefined
behaviour. I would like to understand which statement invokes that
undefined behaviour. Which rule in the language states that it is
undefined behaviour. Thanks a lot for your valuable time.

Regards,
Mohan.


f.hoerner@web.de (Friedhelm Hoerner) wrote in message news:<4c93811c.0403072317.6322289d@posting.google.com>...
> mohanasundaram@msn.com (Mohanasundaram) wrote in message news:<9bb9619e.0403040142.28b9da4b@posting.google.com>...
> > Hi All,
> >
> >      I have the following question asked by my friend.
> >
> > /*Copiled using C++ compiler*/
> > #include <stdio.h>
> >
> > int main()
> > {
> >  const int i = 10;
> >  int *p = (int *)&i;
> >  ++(*p);
> >  printf("%d\n",i);
> >  printf("%d\n",*p);
> >  return 0;
> > }
> >
> > The output is
> > 10
> > 11
> >
>
> Others already pointed out: it is undefined behaviour. So the compiler
> may create anything including code that formats your harddisk. OTOH
> compilers contain some logical behaviour so the compiler will probably
> not create such exotic code;-).
>
> A (guessed) explanation for the output you see:
>
> First you told the compiler that i is constant with value 10. therefor
> the compiler may substitute every use of i with 10. This explains the
> first printf statement.
> With the definition of int* p the need for an adress of i arises. So
> the compiler will put i into memory (initialized with 10) and give
> it's address to p.
> The static cast is a lie, but the compiler assumes you know what you
> do (do you?) and keeps quiet. The increment may fail if the compiler
> puts i into some write protected memory - then you get at least a
> runtime exception.
> If the increment doesn't fail (write protected memory is perhaps not
> available in the given architecture) the output of the second printf
> then shows the expected result.
>
> > /*Copiled using C compiler*/
>  [...]
> >
> > The output is
> > 11
> > 11
> >
> [...]
>
> I don't know why the compiler doesn't substitute i with the value 10
> here but I guess its for compatibility reasons that a constant integer
> gets some place in memory which will be referred to on access.
>
> But I repeat it's undefined behaviour and anything else may happen
> too.
>
> Friedhelm.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Mohanasundaram" <mohanasundaram@msn.com> wrote in message news:9bb9619e.0403090812.485c9e8f@posting.google.com...
> Hi All,
>
>      Can you please tell me which statement causes that undefined
> behaviour. The above posts say that the program invokes undefined
> behaviour. I would like to understand which statement invokes that
> undefined behaviour. Which rule in the language states that it is
> undefined behaviour. Thanks a lot for your valuable time.

We told you.   ++(*p) will modify the variable initially declared const
(i).  This is undefined behavior.   Casting it makes it compile, but it doesn't
make it legal.

Paragraph 4 of 7.1.5.3  lays out the rule:

Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const

object during its lifetime (3.8) results in undefined behavior.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mohanasundaram wrote:
>      Can you please tell me which statement causes that undefined
> behaviour.

The increment.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ron@sensor.com ("Ron Natalie") wrote:
>
>"Mohanasundaram" <mohanasundaram@msn.com> wrote:
>> Hi All,
>>
>>      Can you please tell me which statement causes that undefined
>> behaviour. The above posts say that the program invokes undefined
>> behaviour. I would like to understand which statement invokes that
>> undefined behaviour. Which rule in the language states that it is
>> undefined behaviour. Thanks a lot for your valuable time.
>
>We told you.   ++(*p) will modify the variable initially declared const
>(i).  This is undefined behavior.   Casting it makes it compile, but it doesn't
>make it legal.
>
>Paragraph 4 of 7.1.5.3  lays out the rule:
>
>Except that any class member declared mutable (7.1.1)
>can be modified, any attempt to modify a const
>object during its lifetime (3.8) results in undefined behavior.

For C99 there is similar wording in 6.7.3#5:

  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. [...]

Regards
--
Irrwahn
(irrwahn33@freenet.de)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]