By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,301 Members | 1,752 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,301 IT Pros & Developers. It's quick & easy.

Assigning string constant to char* without malloc

P: n/a
I am able to compile the following code and get "hello" as ouput
everytime I execute it:-

#include <stdio.h>
int main (void)
{
char *str;
str="hello";
puts(str);
return 0;
}

Before assigning the string constant "hello" to str, str in this case
doesn't points to a valid memory location (it points to nowhere). I
guess it is not correct to do this assignment, but it produces right
output eveytime. Is the compiler allocating necessary memory by itself,
automatically? If yes, where is this memeory; in stack or the heap or ??


Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Senthilraja <se**********@adcc.alcatel.be> scribbled the following:
I am able to compile the following code and get "hello" as ouput
everytime I execute it:- #include <stdio.h>
int main (void)
{
char *str;
str="hello";
puts(str);
return 0;
} Before assigning the string constant "hello" to str, str in this case
doesn't points to a valid memory location (it points to nowhere). I
guess it is not correct to do this assignment, but it produces right
output eveytime. Is the compiler allocating necessary memory by itself,
automatically? If yes, where is this memeory; in stack or the heap or ??


First off, yes it is true that before the assignment, str doesn't point
to anywhere valid.
However, the code is completely correct, safe, kosher and hunky-dory.
This is because the assignment str="hello" does not write anything to
the place where str points. Instead it makes str point at a different
place.
When the compiler sees that you use the string literal "hello", it
reserves memory for it automatically (either at compile or at run time)
and then str can be made to point to it. Where that memory is reserved -
at the stack or the heap or the Mythical Elephants' Graveyard - is not
specified at all in the standard.
Note that any attempt to modify the string that str points to will
result in undefined behaviour.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The large yellow ships hung in the sky in exactly the same way that bricks
don't."
- Douglas Adams
Nov 13 '05 #2

P: n/a
ark

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bi**********@oravannahka.helsinki.fi...
Senthilraja <se**********@adcc.alcatel.be> scribbled the following:
I am able to compile the following code and get "hello" as ouput
everytime I execute it:-
#include <stdio.h>
int main (void)
{
char *str;
str="hello";
puts(str);
return 0;
}

Before assigning the string constant "hello" to str, str in this case
doesn't points to a valid memory location (it points to nowhere). I
guess it is not correct to do this assignment, but it produces right
output eveytime. Is the compiler allocating necessary memory by itself,
automatically? If yes, where is this memeory; in stack or the heap or ??


First off, yes it is true that before the assignment, str doesn't point
to anywhere valid.
However, the code is completely correct, safe, kosher and hunky-dory.
This is because the assignment str="hello" does not write anything to
the place where str points. Instead it makes str point at a different
place.
When the compiler sees that you use the string literal "hello", it
reserves memory for it automatically (either at compile or at run time)
and then str can be made to point to it. Where that memory is reserved -
at the stack or the heap or the Mythical Elephants' Graveyard - is not
specified at all in the standard.
Note that any attempt to modify the string that str points to will
result in undefined behaviour.

^^^^^^^^^^^^^^^^^^^^^^^
.... which is why the code is not kosher, but with _const_ shar *str; it
would be.
With all probably, the compiler creates "hello" in a const segment AND
depending on a compiler switch it copies the string into a place in the
initialized data segment. If it does so, there will be no warning and you
_can_ modify the string. If it does not, it should issue at least a warning.
BTW, a copy, if created, occupies space for the life of the program.
Ark
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The large yellow ships hung in the sky in exactly the same way that bricks don't."
- Douglas Adams

Nov 13 '05 #3

P: n/a
"ark" <ar****@comcast.net> writes:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bi**********@oravannahka.helsinki.fi...
Note that any attempt to modify the string that str points to will
result in undefined behaviour. ^^^^^^^^^^^^^^^^^^^^^^^
... which is why the code is not kosher, but with _const_ shar *str; it
would be.


Sure it's kosher. String literals have type "array of
unmodifiable char", not "array of const char". The string can't
be modified, but it can be assigned to a char * without a cast.
With all probably, the compiler creates "hello" in a const segment AND
depending on a compiler switch it copies the string into a place in the
initialized data segment.
This is likely, though not required by the standard.
If it does so, there will be no warning and you _can_ modify
the string. If it does not, it should issue at least a warning.
A warning for what? For trying to modify the string? That would
be handy, but it is not required by the standard, and I'm not
sure that any compilers give such a warning. For assigning a
string literal to a char *? That would be allowed by the
standard--compilers may warn about anything they like--but not
required, and in itself it would not cause a conforming
implementation to fail.
BTW, a copy, if created, occupies space for the life of the
program. Ark


Depends on how you make the copy. A copy into an automatic
buffer is only guaranteed to occupy storage until the end of its
automatic lifetime.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.