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

[Flash Gordon]

On Thu, 08 Jan 2004 21:00:37 GMT
tinybyte <ne******@box.i t> wrote:

<snip>

As I said above, I don't want to write crap code with those tricks in
it. I stick to the standard when writing code, or at least I try to :)
I want to write the best code I can, and be aware of *why* that kind
of code results in undefined behavior.
The *only* reason code invokes undefined behaviour is because it does
something the standard says is undefined behaviour. It is nothing to do
with what compilers do when said undefined behaviour is invoked.
This is *understanding* . The
other way is just *believing*, and that could lead to mistakes too.

Knowing what any given set of compilers and options does with undefined
behaviour does not tell you anything about undefined behaviour. It does
not even tel you why the behaviour was originally specified as
undefined since those choices where made before any compiler you are
likely to use was written.

Do you have to see someone killed by having mains electricity connected
across their heart before you believe it is a bad idea? Do you have to
write off your computer before agreeing that connecting the power supply
to the motherboard incorrectly (something which *was* possible with AT
PSUs)?
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.

[Alexander Bartolich]

begin followup to tinybyte:

[...] I don't want that. I will keep programming in C for my
whole life, because I love it.

Mhh. Puts the thread into different perspective.
There are a few strategies to avoid this kind of debugging experience.

The good old days : #define SYMBOL LITERAL;
Only for limited range : enum { SYMBOL = LITERAL };
Use write-protection of OS : static const TYPE = LITERAL;
Performance be damned : TYPE SYMBOL(void) { return LITERAL; }

--
Für Google, Tux und GPL!

[Ben Pfaff]

Alexander Bartolich <al************ *****@gmx.at> writes:

The good old days : #define SYMBOL LITERAL;
Only for limited range : enum { SYMBOL = LITERAL };
Use write-protection of OS : static const TYPE = LITERAL;
Performance be damned : TYPE SYMBOL(void) { return LITERAL; }

Better performance : inline TYPE SYMBOL(void) { return LITERAL; }
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro

[Christian Bau]

In article <pa************ *************** *@box.it>,
tinybyte <ne******@box.i t> 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.

"Undefined behavior" means that anything can happen, and whatever
happens is your fault (the programmers fault), and not the fault of the
compiler. And whatever the compiler does is correct: When the behavior
is undefined, then _any_ behavior that the compiler produces is correct
behavior.

[Christian Bau]

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

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.

True. The programmer who wrote that code deserves a kick in the ***.
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.
Yes, the code that some stupid programmer wrote 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.

True, some people shouldn't be allowed to write C programs.

[Arthur J. O'Dwyer]

On Thu, 8 Jan 2004, Ben Pfaff wrote:

Alexander Bartolich <al************ *****@gmx.at> writes:

The good old days : #define SYMBOL LITERAL;
Only for limited range : enum { SYMBOL = LITERAL };
Use write-protection of OS : static const TYPE = LITERAL;
Performance be damned : TYPE SYMBOL(void) { return LITERAL; }

Better performance : inline TYPE SYMBOL(void) { return LITERAL; }

After that last guy gets kicked upstairs: #define SYMBOL LITERAL

;-)
-Arthur

[Keith Thompson]

Kevin Goodsell <us************ *********@never box.com> writes:

tinybyte wrote:

[...]

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

When I use "%p", I find it useful to add something to make it clear
that the value being displayed is a pointer (since the output
generated by "%p" often looks like a number). I usually just surround
it with square brackets. For example:

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

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Jack Klein]

On Thu, 8 Jan 2004 15:02:12 +0530, "user" <no**@none.co m> wrote in
comp.lang.c:

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
The C standard requires that a compiler issue a diagnostic for
constraint violations, of which there are none in your code. The
standard does not define "error messages" or "warning messages",
either would suffice to meet the standard's requirements for a
diagnostic.
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, the code invokes undefined behavior. Attempting to change the
value of an object defined as const is undefined behavior. A compiler
is never required by the standard to issue any diagnostic for
undefined behavior.

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[J. J. Farrell]

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

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.

That would be the ideal. A major part of the thinking behind the
concept of 'undefined behaviour' in C is that many of these
situations are extremely hard to detect - in practice, more or
less impossible in some cases with compiler technology as it was
around the time that the Standard was first created. The complexity
that would have to be added to detect all possible cases of undefined
behaviour is huge. Some would say that a compiler which added all
this error detection would have a higher quality of implementation;
others consider that this effort is better spent on improving the
compilation of correct code, perhaps by improving optimization.

The essential thinking is that the compiler can assume that coding
errors that lead to undefined behaviour never occur - it doesn't
need to consider the possibility in any way. This sometimes ends up
with the program accidentally doing exactly what the coder wanted,
but often with it misbehaving in bizarre ways. It will often do
the "right" thing if optimization is disabled, and go "wrong" when
optimized. All but one of the many instances I've looked at of "a
bug in the optimizer" have turned out to be undefined behaviour in
the code being compiled.

[Keith Thompson]

tinybyte <ne******@box.i t> writes:

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.

That's simply not possible.

The major reason that the concept of "undefined behavior" exists in
the C language is that many errors cannot be detected, and many other
errors cannot be detected portably or without considerable runtime
overhead.

Consider something as simple as this:

void foo(int *ptr)
{
*ptr = 42;
}

If ptr is a valid pointer-to-int, this is ok. If it's not (either
because it's a null pointer or because it's invalid for any of a
number of other reasons), it invokes undefined behavior. If the
implementation were required to explicitly detect this error, it would
have to have a way of determining whether a pointer is valid; there's
no good way to do that.

I think most languages have instances of this kind of thing. The
better-defined ones enumerate what they are. C is somewhat unusual in
the number of things that invoke undefined behavior (some other
languages either require more run-time checking or disallow some of
the dangerous things, like pointer arithmetic, that C allows), but
it's difficult, if not impossible, to eliminate them entirely without
severely limiting the power of the language.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"