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

 

[Vijay Kumar R Zanvar]

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);

return 0;

}
Output:
value of num is 100(200)

On my system the output is

value of num is 200(200)

[..]

 

[Frane Roje]

I think the int* p find a new adress in order to write something to that
adress.
If you write const int* ip in that case the adress of ip can't change.
If you assign anything to int *ip it will be assigned to an adress which the
computer will find in order to store it there.

 

[user]

Hello,

I am sorry. After reading the post myself, I felt that the post is
incomplete in itself.

Well when I tried this exercise I expected the code to fail in the
compilation phase with an error ( not a warning). It did not, and the output
made me think how is this possible to have 2 different value when I am
pointing to the same memory location? I exptected the output to 2 100s or 2
200s. Is 'num' variable pointing some where ????

My question is how is the output different? Is the program performing an
undefined behavior?

Thanks

 

[user]

Hello,

I am sorry. After reading the post myself, I felt that the post is
incomplete in itself.

Well when I tried this exercise I expected the code to fail in the
compilation phase with an error ( not a warning). It did not, and the output
made me think how is this possible to have 2 different value when I am
pointing to the same memory location? I exptected the output to 2 100s or 2
200s. Is 'num' variable pointing some where ????

My question is how is the output different? Is the program performing an
undefined behavior?

Thanks

Hello,

Sorry for top posting (in my earlier post). I am trying this on a OpenVMS
Alpha system.

Thanks

 

[Martin Dickopp]

#include stdio

Do you mean

#include <stdio.h>

?

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

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

You forgot to return something from the `main' function. Insert

return 0;

}

The behavior of this program is undefined according to section 6.7.3#5 of
the standard: "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. [...]"

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.

My wild guess says that this trick is handled at the compiler level. Am
I correct?

I don't know what you mean by "this trick".

Martin

 

[Martin Dickopp]

Please don't top-post. Please don't put a lot of quoted material in your
signature. Your signature is 36 lines long, which is 32 lines more than
the allowed four lines.

I think the int* p find a new adress in order to write something to that
adress.

I'm not sure if I understand you correctly, but you seem to believe that
the definition of a pointer automatically allocates memory. That is not the
case.

If you write const int* ip in that case the adress of ip can't change.

Once you have defined a variable, pointer or other type, const-qualified
or not, its /address/ cannot change throughout its lifetime.

The /value/ of `ip' can certainly be changed. The object pointed to by
`ip' cannot (unless another access path to the same object exists).

Martin

 

[tinybyte]

Well when I tried this exercise I expected the code to fail in the
compilation phase with an error ( not a warning). It did not, and the output
made me think how is this possible to have 2 different value when I am
pointing to the same memory location? I exptected the output to 2 100s or 2
200s. Is 'num' variable pointing some where ????

I'll try to explain this way:

#include <stdio.h>

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

ip = (int *) &num;
*ip = 200;
printf ("value of num is %d(%d) \n", num, *ip);
printf ("address of ip is 0x%p\n", ip);
printf ("address of num is 0x%p\n", &num);
}

this will print out the addresses the pointers are pointing to.
The output is as expected: the address is the same.

Now, I'm not sure of what i'm about to say, but well, correct me if
I am wrong

I *think* that the problem is in what we had declared constant, or, better,
in what the compiler sees as a constant.

const int num = 100, we have declared the variable num, it's *name*,
to be constant. We cannot change the value *through that symbol*,
but nothing prevents us by changing it by other means.
Let's assume this declaration is the same as

int *const num = 100;

This is a constant pointer.
You cannot change it's address, but you can change the data.
The other way is

const int *num = 100;

Here the data is constant, we cannot change the data but we can change the
address the variable points to.
So, AFAIK, it may be correct to make the assumption that when we declare
a

const int num

we are actually declaring (or the compiler is actually going to change it
to) the former:

int *const num

that is a constant pointer. But sintactically we handle it as a normal
variable, with the constraint that we cannot change it's value
*through the symbol itself*, and being it a normal variable, and not a
pointer, we cannot either directly change it's address. But indirectly
we can.

So accessing it by

num = 100;

is only a sintactical error, because the compiler knows that that
*variable name* is constant.

I mean, I *think* that the compiler doesn't make assumptions on the data
pointed by that name, but only on the name itself.

Bye
Daniele "tinybyte" Milan

 

[Martin Dickopp]

I'm not sure if I understand you correctly, but you seem to believe that
the definition of a pointer automatically allocates memory. That is not the
case.

I noticed that my statement is ambiguous. To clarify, the definition of
a pointer automatically allocates memory for the pointer itself, but it
doesn't allocate any memory at the location the pointer points to.

Martin

 

[Kevin Goodsell]

[You have top-posted yet again. Please stop.]

I think the int* p find a new adress in order to write something to that
adress.

I can't make sense of that at all.

If you write const int* ip in that case the adress of ip can't change.

When /can/ the address of a named object change?

If you assign anything to int *ip it will be assigned to an adress which the
computer will find in order to store it there.

I can't make sense of that either.

-Kevin

 

[tinybyte]

On my system the output is

value of num is 200(200)

on my system is 200(200) too, using gcc.
I think that being an undefined behavior according to the standard,
as Martin pointed out, the developers of the compiler used by user
have made up a mess. gcc handles it logically, as I have explained
(hope to be correct) in my earlier followup.

Now, user, which compiler have you used? I'm curious about it.

Bye
Daniele "tinybyte" Milan

 

[Kevin Goodsell]

Hello,

Please don't top-post. It's rude.

I am sorry. After reading the post myself, I felt that the post is
incomplete in itself.

Well when I tried this exercise I expected the code to fail in the
compilation phase with an error ( not a warning). It did not, and the output
made me think how is this possible to have 2 different value when I am
pointing to the same memory location? I exptected the output to 2 100s or 2
200s. Is 'num' variable pointing some where ????

My question is how is the output different? Is the program performing an
undefined behavior?

Yes. This should be fairly obvious.

-Kevin

 

[Kevin Goodsell]

I'll try to explain this way:

#include <stdio.h>

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

ip = (int *) &num;
*ip = 200;
printf ("value of num is %d(%d) \n", num, *ip);
printf ("address of ip is 0x%p\n", ip);
printf ("address of num is 0x%p\n", &num);

These last two statements invoke undefined behavior. %p is for void
pointers only. It's also a little silly to add your own 0x prefix. On
some implementations you'll get output like

0x0x034aff30

}

this will print out the addresses the pointers are pointing to.
The output is as expected: the address is the same.

Now, I'm not sure of what i'm about to say, but well, correct me if
I am wrong

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.

-Kevin

 

[Frane Roje]

When /can/ the address of a named object change?
sorry I wanted to say the adress that the pointer points to
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.

 

[tinybyte]

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. Just saying "according to the
standard" isn't enough. According to the standard that piece of code
is broken, but it actually executes, and sometimes properly.
You're not compiling programs with the standard, but with compilers.

Daniele

 

[tinybyte]

These last two statements invoke undefined behavior. %p is for void
pointers only. It's also a little silly to add your own 0x prefix. On

I admit it's silly
Undefined behavior? then cast that pointers to void and you're done.

...
printf ("address of ip is %p\n", (void *)ip);
printf ("address of num is %p\n", (void *)&num);
...

Daniele

 

[Richard Bos]

on my system is 200(200) too, using gcc.
I think that being an undefined behavior according to the standard,
as Martin pointed out, the developers of the compiler used by user
have made up a mess.

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.

gcc handles it logically,

s/logically/lazily/, IYAM.

Richard

 

[Richard Bos]

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.

Wrong, and wrong. The OP's compiler is quite correct, and gcc handles
this code as it _may_, not as it _should_ be handled. The code invokes
undefined behaviour - changing the value of a const object - and _any_
behaviour after that is correct.

Just saying "according to the
standard" isn't enough. According to the standard that piece of code
is broken, but it actually executes, and sometimes properly.

For _some_ values of properly. _My_ value of properly is the reverse -
I'd rather have a compiler that compiles correct code to a fast
executable than one that compiles incorrect code to appear to be
correct. Hence, I'd prefer the OP's compiler to gcc.

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

A meaningless statement, really.

Richard

 

[Thomas Stegen]

Richard Bos wrote:

s/logically/lazily/, IYAM.

^^^^
?
DYM "ITYM"?

 

[Frane Roje]

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