question on const

[Thomas Stegen]

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.

 

[Richard Bos]

^^^^
DYM "ITYM"?

If You Ask Me.

Richard

 

[Richard Bos]

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

 

[Thomas Stegen]

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.

 

[Dik T. Winter]

>
> 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.

 

[Thomas Stegen]

There's always a good reason to try to know how things really works.
Now we had discovered that that compiler is broken.

No we have not.

gcc handles the
thing correctly, as it should be.

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

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

Yes it is.

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

There is no properly.

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.

Try compiling with the optimising flags for gcc and be prepared to learn
a valuable lesson.

 

[Dik T. Winter]

>
> 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]

> 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.

>
> s/logically/lazily/, IYAM.

Not lazy...

 

[tinybyte]

No we have not.

You're right.

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

You're right.

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.

There is no properly.

You're right.

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

 

[tinybyte]

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

 

[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

 

[pete]

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]

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.


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.

 

[tinybyte]

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]

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]

> On Thu, 08 Jan 2004 12:21:13 +0000, Dik T. Winter wrote:
>
>
> 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.

 

[pete]

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 ?

 

[tinybyte]

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]

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]

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