const variable reassignment

[rahul8143]

hello,
Check following code that changes const i value.
include <stdio.h>
int main()
{
const int i=10;
int *p;
p=&i;
(*p)++;
printf("\n %d",i);
return 0;
}

we know that (*p)++ is same as *p=*p+1 then why i am not allowed to
directly assign new value to i
i.e. *p=15;
Isn't *p=*p+1 is reassinging new value to i?

 

[akarl]

hello,
Check following code that changes const i value.
include <stdio.h>
int main()
{
const int i=10;
int *p;
p=&i;
(*p)++;
printf("\n %d",i);
return 0;
}

we know that (*p)++ is same as *p=*p+1 then why i am not allowed to
directly assign new value to i
i.e. *p=15;
Isn't *p=*p+1 is reassinging new value to i?

In your code you say that `i' should be constant so what do you expect?

August

 

[Flash Gordon]

hello,
Check following code that changes const i value.

Which means it is invoking undefined behaviour.

include <stdio.h>
int main()
{
const int i=10;
int *p;
p=&i;

Doesn't you compiler generate a warning for this? If not, you need to
turn up the warnings it generates to a sensible level.

(*p)++;
printf("\n %d",i);
return 0;
}

we know that (*p)++ is same as *p=*p+1 then why i am not allowed to
directly assign new value to i
i.e. *p=15;

You are not allowed to because the standard says it invoked undefined
behaviour, which means that anything can happen. Using the pointer to
increment it is also not allowed, and I don't know what makes you think
it is allowed.

Isn't *p=*p+1 is reassinging new value to i?

Yes, and it is not allowed.

Only declare things as const if they will never be modified, that is
what const is for. If they will be modified, then obviously they should
not be declared const.

 

[Cong Wang]

hello,
Check following code that changes const i value.
include <stdio.h>
int main()
{
const int i=10;
int *p;
p=&i;
(*p)++;
printf("\n %d",i);
return 0;
}

we know that (*p)++ is same as *p=*p+1 then why i am not allowed to
directly assign new value to i
i.e. *p=15;
Isn't *p=*p+1 is reassinging new value to i?

Modifying a const through a pointer is an undefined behaviour.
Exactly,(*p)++ is different from *p=*p+1.

 

[Emmanuel Delahaye]

Check following code that changes const i value.
include <stdio.h>
int main()
{
const int i=10;
int *p;
p=&i;

I have a warning here with my compiler. (wrong type).

(*p)++;
printf("\n %d",i);
return 0;
}

we know that (*p)++ is same as *p=*p+1 then why i am not allowed to
directly assign new value to i

Because the 'const' qualifier explicitely prevents against it.

i.e. *p=15;
Isn't *p=*p+1 is reassinging new value to i?

Yes. It may work or not.

The whole thing is a design issue. If a variable has been qualified
'const', it means, in the developper's mind, that its value is
invariant, so, trying to modify it is a violation of a design rule.

Of course, you can override it via a pointer and some ugly typecast,
but under your own responsability. Don't come here and cry if the whole
program is not yet working as expected...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

 

[Flash Gordon]

Modifying a const through a pointer is an undefined behaviour.
Yes.

Exactly,(*p)++ is different from *p=*p+1.

What do you mean? (*p)++ increments the value stored at *p, i.e. in
terms of the effect on i in the abive code it is the *same* as *p=*p+1
and is undefined behaviour.

 

[Keith Thompson]

(e-mail address removed) wrote: [...]

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

[...]
You are not allowed to because the standard says it invoked undefined
behaviour, which means that anything can happen. Using the pointer to
increment it is also not allowed, and I don't know what makes you think
it is allowed.

You're not allowed to modify i directly, as in
i ++;
because it's a constraint violation.

You *are* "allowed" to modify it indirectly, in the sense that the
compiler isn't (necessarily) going to stop you. Declaring i as
"const int" means you're promising not to modify i; it deons't mean
that the compiler will always hold you to your promise. If you lie to
the compiler by declaring i as "const" and then modifying it, the
compiler isn't obligated to do anything in particular.

 

[Flash Gordon]

(e-mail address removed) wrote:
[...]

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

[...]

You are not allowed to because the standard says it invoked undefined
behaviour, which means that anything can happen. Using the pointer to
increment it is also not allowed, and I don't know what makes you think
it is allowed.

You're not allowed to modify i directly, as in
i ++;
because it's a constraint violation.

You *are* "allowed" to modify it indirectly, in the sense that the
compiler isn't (necessarily) going to stop you. Declaring i as
"const int" means you're promising not to modify i; it deons't mean
that the compiler will always hold you to your promise. If you lie to
the compiler by declaring i as "const" and then modifying it, the
compiler isn't obligated to do anything in particular.

Including not being obliged to produce a program that does what the OP
expects. I know the compiler does not have to produce a diagnostic, but
since the standard does not define the term, "not allowed to," as far as
I am aware I don't think it unreasonable to say that you are not allowed
to do it.

 

[Keith Thompson]

Including not being obliged to produce a program that does what the OP
expects. I know the compiler does not have to produce a diagnostic,
but since the standard does not define the term, "not allowed to," as
far as I am aware I don't think it unreasonable to say that you are
not allowed to do it.

Sure, but someone unfamiliar with the nuances of constraint violations
and undefined behavior might easily read "not allowed to" as implying
that the error will be diagnosed.

 

[Flash Gordon]

Keith Thompson wrote:

Sure, but someone unfamiliar with the nuances of constraint violations
and undefined behavior might easily read "not allowed to" as implying
that the error will be diagnosed.

OK, I'll accept that people might make that inference. I don't having
not always been told off for doing things I was not allowed to do, but I
can see that others might.

 

[elsdy]

I try to compile and run the same code you show.
but i have got massage that say cannot convert from 'const int *__w64'
to 'int *'
I used to try that with visual 2005 express edition beta.

I think that if the compiler is correct, error message is printed with
above message. and
wrong part is that p=&i.

 

[Flash Gordon]

I try to compile and run the same code you show.

What code? How do you know that everyone has seen the post you are
replying to? Even if they have, a number of us set news readers to only
show unread posts so that we can easily see what is new.

Instructions have been posted here LITERALLY hundreds of times saying
how you can post properly using that horrible google interface. Read
CBFalconer's sig for a start. Also read the group (like you should
ALWAYS do before posting to the first time) an you will also see lots of
complaints.

but i have got massage that say cannot convert from 'const int *__w64'
to 'int *'

__w64 is not part of standard C so we don't know anything about it here.

I used to try that with visual 2005 express edition beta.

I think that if the compiler is correct, error message is printed with
above message. and
wrong part is that p=&i.

Well, without knowing the types of p and i since you don't provide any
context how can we know WTF is going on?