question on const

[user]

Hello,

Here is the program

#include stdio

int main(void)
{
const int num = 100;
int *ip;

ip = (int *)#
*ip = 200;
printf("value of num is %d(%d) \n", num, *ip);
}
Output:
value of num is 100(200)

The output says that *ip is changed and 'num' is unchanged. How is this
possible when both of them point to the same memory location? My wild guess
says that this trick is handled at the compiler level. Am I correct?

Even when the memory location is accessable and the contents changed the
'const integer' is unaffected.

Thanks

[Jean-Michel Collard]

It seems to be compiler dependent and even changes with optimisations.

<jm@paris>13:42 :33~$gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.0/specs
Configured with: ../gcc/configure --prefix=/usr --enable-shared
--enable-static --enable-debug --enable-profile --verbose --enable-interpreter
--enable-haifa --enable-long-long --enable-languages=c,c++ --with-system-zlib
--enable-__cxa_atexit --enable-threads=posix
Thread model: posix
gcc version 3.4.0

<jm@paris>13:43 :51~$gcc ess.c
<jm@paris>13:44 :26~$./a.out
value of num is 200(200)

<jm@paris>13:44 :28~$gcc -Wall -W -O2 ess.c
ess.c: In function `main':
ess.c:11: warning: control reaches end of non-void function
<jm@paris>13:44 :41~$./a.out
value of num is 100(200)

Regards,

Jm

user wrote:

Hello,

Here is the program

#include stdio

int main(void)
{
const int num = 100;
int *ip;

ip = (int *)&num;
*ip = 200;
printf("value of num is %d(%d) \n", num, *ip);
}
Output:
value of num is 100(200)

The output says that *ip is changed and 'num' is unchanged. How is this
possible when both of them point to the same memory location? My wild guess
says that this trick is handled at the compiler level. Am I correct?

Even when the memory location is accessable and the contents changed the
'const integer' is unaffected.

Thanks

[pete]

Thomas Stegen wrote:

Frane Roje wrote:

I'm not sure about this but I think that when you
write int *p=20;
the compiler will handle the memmory allocation
of the int which has '20' value.

No, it will not. Unless You make p point somewhere decent first the
above is wrong.

int *p=20;
is an initialization, so you can't make p point somewhere decent first.

Also, a cast is required to assign an integer value to a pointer,
and the result might not be defined.

--
pete

[pete]

tinybyte wrote:

On Thu, 08 Jan 2004 12:21:13 +0000, Dik T. Winter wrote:

In what way is that compiler broken and gcc not? A compiler is allowed,
when it sees a declaration like
const int num = 100;
to assume that when you use "num" later in the program, your intention
is that the value 100 should be used.

But it returns the same address. That's inconsistent. It should be not
permitted if not according to the standard, but it is. This means:
compilers implementations are broken,
not strictly following the standard.

What is proper execution with a piece of code to which the standard
assigns no meaning?

There is no proper execution, now I know.

I hope you understand that the compiler can't be wrong
when there is no proper execution.

--
pete

[tinybyte]

On Thu, 08 Jan 2004 13:20:48 +0000, pete wrote:

I hope you understand that the compiler can't be wrong
when there is no proper execution.

Compilers simply must not permit such a thing, if it gives an
undefined behavior.

Daniele

[Alex]

"tinybyte" <ne******@box.i t> wrote in message
news:pa******** *************** *****@box.it...

On Thu, 08 Jan 2004 13:20:48 +0000, pete wrote:

I hope you understand that the compiler can't be wrong
when there is no proper execution.

Compilers simply must not permit such a thing, if it gives an
undefined behavior.

Are you trying to say that all possible undefined behaviour must be detected
at compile time, resulting in an error? If not, what are you trying to say?

[Dik T. Winter]

In article <pa************ *************** *@box.it> tinybyte <ne******@box.i t> writes:

On Thu, 08 Jan 2004 12:21:13 +0000, Dik T. Winter wrote:

In what way is that compiler broken and gcc not? A compiler is allowed,
when it sees a declaration like
const int num = 100;
to assume that when you use "num" later in the program, your intention
is that the value 100 should be used.

But it returns the same address. That's inconsistent.

No that is not inconsistent. The address *must* remain the same.
The question is: "must the compiler look at that address to see what
is there?" The answer to that question is *no* if the variable is
declared to be const, because the compiler is allowed to assume that
the value is not changed.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[pete]

tinybyte wrote:

On Thu, 08 Jan 2004 13:20:48 +0000, pete wrote:

I hope you understand that the compiler can't be wrong
when there is no proper execution.

Compilers simply must not permit such a thing, if it gives an
undefined behavior.

Is that how you think C is,
or is that your opinion on how you think C should be ?

--
pete

[tinybyte]

On Thu, 08 Jan 2004 14:20:15 +0000, Alex wrote:

Are you trying to say that all possible undefined behaviour must be detected
at compile time, resulting in an error? If not, what are you trying to say?

Yes, they should be detected, and result in an error.

Daniele

[tinybyte]

On Thu, 08 Jan 2004 14:54:22 +0000, pete wrote:

tinybyte wrote:
or is that your opinion on how you think C should be ?

Is an opinion on how C compilers should be.

Daniele

[tinybyte]

On Thu, 08 Jan 2004 14:31:51 +0000, Dik T. Winter wrote:

No that is not inconsistent. The address *must* remain the same.
The question is: "must the compiler look at that address to see what
is there?" The answer to that question is *no* if the variable is
declared to be const, because the compiler is allowed to assume that
the value is not changed.

The compiler is allowed to assume that the value it's not changed, but
sometimes it is changed, sometimes not, depends on optimization.
This is inconsistent behavior for me, and in C programming this should
not be ALLOWED. That is all I'm talking about.
I'm trying to say that compilers aren't perfect. And that all those
standards everyone here care so much about are not of any help in this case.
A value that cannot be changed has been changed, under certain conditions.
That means something is broken.

Is the same as you have an application that normally gives perfect output,
but by using it in a different way it was written for, you can screw up
the whole thing. You should not be allowed to use it that way.
If you can, there is a bug.

Bye
Daniele