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

[Thomas Stegen]

Richard Bos wrote:

s/logically/lazily/, IYAM.

^^^^
?
DYM "ITYM"?

:)

--
Thomas.

[Frane Roje]

But if I use a char* p="test";
In that case the computer will allocate some space for the array,
right?

--

---------------------------
Time to get it done!

Remove (d*elete*) to reply

[Thomas Stegen]

Frane Roje wrote:

But if I use a char* p="test";
In that case the computer will allocate some space for the array,
right?

Yes, but this is different. The compiler will find memory for the string
literal, then you make the pointer point to it. (Note that the string
cannot be changed).

Memory is also allocated for the string when you do:

puts("test");

It is in fact also not impossible for the string in the call to puts and
the string pointed to by p to be the same string. Remember that the
value you get from evaluating "test" is a pointer. Also in the above you
are assigning to the pointer, not to wherever the pointer is pointing.

In the case of

int *ip;
*ip = 42;

You are dereferencing ip and you get whatever it is pointing to. Bad
thing. Note that 42 evaluated to an int not an address.

--
Thomas.

[Richard Bos]

Thomas Stegen <ts*****@cis.st rath.ac.uk> wrote:

Richard Bos wrote:

s/logically/lazily/, IYAM.

^^^^
DYM "ITYM"?

If You Ask Me.

Richard

[Richard Bos]

"Frane Roje" <frane.roje(d*e lete*)@st.hinet .hr> wrote:

But if I use a char* p="test";
In that case the computer will allocate some space for the array,
right?

Wrong. It will put a (unwritable!) string constant somewhere in memory,
and then make p point to it. The string constant being unwritable is
significant - you've been writing through that pointer in this thread,
and you cannot reliably do so if p points to a string constant.

Richard

[Dik T. Winter]

In article <bt************ *@news.t-online.com> Martin Dickopp <ex************ ****@zero-based.org> writes:

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?

Since the behavior is undefined, virtually anything can happen.

I think the compiler performs optimisation. That is, because num is
defined to be constant the compiler is allowed to assume that in the
printf num is still 100, so it does not access the value stored at
num at all.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[tinybyte]

On Thu, 08 Jan 2004 12:17:51 +0000, Thomas Stegen wrote:

Now we had discovered that that compiler is broken.
No we have not.

You're right.

gcc handles the
thing correctly, as it should be.

No it does not. There is no right way and there is no wrong way.

You're right.

Just saying "according to the
standard" isn't enough.

Yes it is.

No, it's not. We should go deeper than the standard. I want to learn
more than what's written in the standard, and you're helping me.
If we stop discussing when someone says "According to the standard there
is no reason to speak about this" no one will learn further, even if
possible. Now, please tell me, if this is comp.lang.c "We speak about
everything that is C related" or if "We speak only
about what is written in the C standard". Both are ok for me, but for the
latter I'll know I had to search
somewhere else for the huge deal of information we would be missing.

According to the standard that piece of code
is broken, but it actually executes, and sometimes properly.

There is no properly.

You're right.

You're not compiling programs with the standard, but with compilers.

Which conform to a standard. When the standard says that something is
undefined you cannot rely on the behaviour of any compiler when using
that something. The result will be different between different compilers
hence rendering your code unportable. The result will be different
between different versions of the same compiler. The result will even be
different for the same compiler invoked with different flags.

You're right, but I would have never learned the lesson if I sticked to
the "According to the standard" dogma. We cannot rely on the behaviour of
any compiler, but we can surely speak about every and each different
behaviour, and maybe learn something more. C language is standard +
compilers, not only standard, that's what I meant.
Try compiling with the optimising flags for gcc and be prepared to learn
a valuable lesson.

I've learned NOW. Many thanks to all of you. I want to learn, but I cannot
if we stop when the standard comes in.

Daniele

[Dik T. Winter]

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

On Thu, 08 Jan 2004 10:39:30 +0000, Kevin Goodsell wrote:

There's no good reason to try to explain undefined behavior. In this
case, the compiler probably eliminated a fetch from memory by using the
value 100 directly, since it "knew" that's what the stored value would be.
There's always a good reason to try to know how things really works.
Now we had discovered that that compiler is broken. gcc handles the
thing correctly, as it should be.

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.
According to the standard that piece of code
is broken, but it actually executes, and sometimes properly.

What is proper execution with a piece of code to which the standard
assigns no meaning?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <3f************ ***@news.indivi dual.net> rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

No, the compiler used by the OP is quite as logical as gcc, and possibly
better at optimising - it seems to have diked out all references to the
const int and replaced them with the constant value, which is both a
sensible optimisation, and potentially quite a valuable one.

What gcc probably does do (and the warning message you get suggests it)
is discarding the word const from the declaration of num. Normally gcc
performs the above optimisation.

gcc handles it logically,

s/logically/lazily/, IYAM.

Not lazy...
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[tinybyte]

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.

Bye
Daniele