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

char * ptr = "amit", in which area of memory it is stored (heap,stack,code,global)

P: n/a
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..

Nov 15 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Amit wrote:

char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..


You're close.
The rules of C say that
an attempt to write to an object identified by a string literal,
causes undefined behavior.
str1 points to an object identified by a string literal.
Also, you need to make sure you have enough room for strcat.

char *str1 = "amit";
char str2[sizeof "amit" - 1 + sizeof "mehta"] = "mehta";

strcat(str2, str1);

--
pete
Nov 15 '05 #2

P: n/a

Amit wrote:
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..

I thing it is wrong because
str1 has the address of the value amit
u have to strcat(*str1,str2)

Nov 15 '05 #3

P: n/a
venkatesh wrote:

Amit wrote:
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section.
Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..


I thing it is wrong because
str1 has the address of the value amit
u have to strcat(*str1,str2)


Get yourself to a compiler and try your idea.
You're very wrong.

*str1 is an expression of type char with a value of 'a',
refering to a byte in a nonwriteable object.
The first argument to strcat must be a pointer to a string
in a writable object that has enough space for the resulting
concatenated string.

--
pete
Nov 15 '05 #4

P: n/a
Amit wrote:
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..


Errors abound, crash or not.

char *str1 = "amit";

This defines "amit" a string constant and assigns its address to str1.
The string constant is perhaps not writeable.

char str2[] = "mehta";

This defines "mehta" a string constant and assigns the string itself to
the array. The type of str2 is now 'array 6 of char'. str2 belongs to
you and is writeable.

strcat(str1, str2);

This might 'work' but cannot be correct. The memory at the end of str1
is not yours.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #5

P: n/a
"Amit" <am************@gmail.com> writes:
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..


The language doesn't define where str1 is stored; it could be carved
into stone tablets.

str1 is a pointer to the array created by the string literal "amit1".
Attempting to write to that array, or attempting to read or write
beyond the end of the array, invokes undefined behavior.

The strcat() call will crash *if you're lucky*. If you're unlucky, it
will seem to work. That's the nature of undefined behavior.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #6

P: n/a
Das

Amit wrote:
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..


Well You are right your program will crash.
Your str1 is assigned to string "amit" when you do strcat() your
progam may not find enough space to append the str2[]. so a SIGSEGV (I
hope) will occour.

This is generally not noticed for small strings. but if your second
string is large enough then you will get SIGSEGV.

Nov 15 '05 #7

P: n/a
On 16 Oct 2005 02:04:32 -0700, "Das" <as*********@gmail.com> wrote in
comp.lang.c:

Amit wrote:
char *str1="amit";
char str2[]="mehta"
strcat(str1,str2);

It will crash, I feel str1 will be stored in code section. Once memory
is allocated, you cannot change or append into this.

Please correct me If I am wrong..
Well You are right your program will crash.


No, he and you are both wrong. Maybe the program will crash, maybe it
wall cause "The Star Spangled Banner" to play from the speakers on
your computer, even if your computer does not have speakers.
Your str1 is assigned to string "amit" when you do strcat() your
progam may not find enough space to append the str2[]. so a SIGSEGV (I
hope) will occour.
Accuracy is highly prized in this group, please do not post answers
when you do not know what you are talking about.

The object 'str1' in the OP's sample code is pointing to a string
literal. Attempting to modify a string literal, such as by passing it
as the destination argument to strcat(), produces undefined behavior
because the C standard specifically says that it does. It has nothing
at all to do with how much space there is.

Once you generate undefined behavior, you no longer have a C program.
The language does not know and does not car what happens next.
This is generally not noticed for small strings. but if your second
string is large enough then you will get SIGSEGV.


"generally not noticed" by whom? It is undefined behavior, pure and
simple, and what happens afterwards is not a C language issue and is
not really topical here.

What your particular compiler or platform does is not what defines the
C language.

--
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.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 15 '05 #8

P: n/a
CoL
In this case , according to ANSI C standard the string literal becomes
the part of read only memory, most obvious the datasection. So the
nature of the char * str actually becomes const char *str1... so you
cant write into it.

Nov 15 '05 #9

P: n/a
"CoL" <ap***********@gmail.com> writes:
In this case , according to ANSI C standard the string literal becomes
the part of read only memory, most obvious the datasection. So the
nature of the char * str actually becomes const char *str1... so you
cant write into it.


One more time. Please provide context when you post a followup.

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

Please complain to Google about their broken interface.

String literals in C are not of type const char*. A string literal is
an array of char (not const); in most contexts, it's implicitly
converted to char* (again, not const). Modifying a string literal is
undefined behavior because the standard specifically says it's
undefined behavior.

It might have made more sense for string literals to be const
(<OT>they are in C++</OT>), but they aren't.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #10

P: n/a
CoL wrote:
In this case ,
In what case? Quote context please. To quote from one of the MANY posts
where this problem and the solution has been stated:

| "If you want to post a followup via groups.google.com, don't use
| the broken "Reply" link at the bottom of the article. Click on "show
| options" at the top of the article, then click on the "Reply" at the
| bottom of the article headers." - Keith Thompson
|
| Your post needs to be able to stand on its own, you shouldn't assume
| that everyone just finished reading the post you are replying to
| before reading yours. Usenet is not an incredibly reliable medium and
| it is often the case that followups, such as yours, make it to a news
| server before the post you are responding to. It is also not rare for
| news readers to screw up the order of posts and followups, Google
| Groups has a number of problems in this area. If you include context,
| these things become non-issues.
according to ANSI C standard the string literal becomes
the part of read only memory,
Not quite, none of the ANSI or ISO C standard require read only memory.
most obvious the datasection. So the
nature of the char * str actually becomes const char *str1... so you
cant write into it.


I'm not sure exactly what you are trying to say, and so I suspect you
have not quite understood the situation.

int main(void)
{
char *ptr="string literal";
*ptr=0;
}
Is syntactically perfectly legal and no compiler is *required* to
complain about it. However, since the standard states that attempting to
modify a string literal is undefined behaviour *anything* can happen if
you run it. The most common things are the program crashing (if the
compiler chooses to place "string literal" in read only memory) andall
string literals ending in "string literal" including the one that says
"This is a string leteral" being affected.

So you are correct if you think that a program is "not allowed" to
modify a string literal, but not if you thing the compiler is required
to complain or if you think the program is guaranteed to crash in a
visible way.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.