why segmentation fault when copying a character?

[Cocy]

Hi,
This might be a sort of FAQ, but I don't see why,
so I would someone help me to understand what's wrong?

I've just created following code which wold trim
white space(s) in a (given) string.
But, it resulted the Segmentation fault, and so as
when running in gdb (saying "Program received signal
SIGSEGV, Segmentaion fault at *p++ = *st++").
The platform is Linux kernel 2.4.27, gcc version
2.95.4 20011002.

/*-------------------------------------*/
#include <stdio.h>
#include <ctype.h>

int main(int argc, char ** argv)
{
char *st = "Hey, how are you?";
char *p, *s;

p = s = st;

while( *st )
{
if ( isspace( (int)*st ) )
st++;
else
*p++ = *st++;
}
*p = '/0';

printf("whitesp ace trimed : %s\n", s);
}

Compile itself doesn't complain anything, and I don't
see what's wrong with copying the character in the
string to the other place (in memory) where should not
overlap the end of the string ('/0') of the original
string.
Colud someone help me to understand what's wrong with
this code?

Thanks and Best Regards,
Cocy

[Christopher Benson-Manica]

Cocy <ku*********@ho tmail.com> spoke thus:

char *st = "Hey, how are you?";
char *p, *s;
p = s = st;

p, s, and st all point at the same string literal. You may not
attempt to modify a string literal; this is most likely the source of
your troubles.

<ot>You can pass an option to gcc to make the code work as is.</ot>

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Mark A. Odell]

ku*********@hot mail.com (Cocy) wrote in
news:55******** *************** ***@posting.goo gle.com:

Hi,
This might be a sort of FAQ, but I don't see why,
so I would someone help me to understand what's wrong?

I've just created following code which wold trim
white space(s) in a (given) string.
But, it resulted the Segmentation fault, and so as
when running in gdb (saying "Program received signal
SIGSEGV, Segmentaion fault at *p++ = *st++").
The platform is Linux kernel 2.4.27, gcc version
2.95.4 20011002.

/*-------------------------------------*/
#include <stdio.h>
#include <ctype.h>

int main(int argc, char ** argv)
{
char *st = "Hey, how are you?";

If you defined this as it really is:

const char *st = "Hey, I cannot be modified!";

the reason should jump out at you (hint: note the 'const' keyword).

--
- Mark ->
--

[Default User]

Cocy wrote:

Hi,
This might be a sort of FAQ, but I don't see why,
so I would someone help me to understand what's wrong?

http://www.eskimo.com/~scs/C-faq/q1.32.html


Brian Rodenborn

[Cocy]

Dear Christopher, Mark, and Brian.

Thank you very much for you guys comment, I really appreciate.
I got it, and I have a lot to learn.

Thank you again!
Cocy

[Richard Bos]

Christopher Benson-Manica <at***@nospam.c yberspace.org> wrote:

Cocy <ku*********@ho tmail.com> spoke thus:

p, s, and st all point at the same string literal.

<ot>You can pass an option to gcc to make the code work as is.</ot>

But this is a very bad idea, because it doesn't get rid of the bug.

Richard

[Jack Klein]

On 12 Oct 2004 18:55:34 GMT, "Mark A. Odell" <od*******@hotm ail.com>
wrote in comp.lang.c:

ku*********@hot mail.com (Cocy) wrote in
news:55******** *************** ***@posting.goo gle.com:

Hi,
This might be a sort of FAQ, but I don't see why,
so I would someone help me to understand what's wrong?

I've just created following code which wold trim
white space(s) in a (given) string.
But, it resulted the Segmentation fault, and so as
when running in gdb (saying "Program received signal
SIGSEGV, Segmentaion fault at *p++ = *st++").
The platform is Linux kernel 2.4.27, gcc version
2.95.4 20011002.

/*-------------------------------------*/
#include <stdio.h>
#include <ctype.h>

int main(int argc, char ** argv)
{
char *st = "Hey, how are you?";
If you defined this as it really is:

const char *st = "Hey, I cannot be modified!";

Bad example. In C, a pointer to string literal has the type 'pointer
to char', and specifically does not have the type 'pointer to const
char'. String literals may or may not be const. Attempting to modify
a string literal in C produces undefined behavior because the standard
specifically says so, not because the type of the string literal is
'array of const char'.

the reason should jump out at you (hint: note the 'const' keyword).

Nope, just plain wrong. There is absolutely no const keyword implied
in any way for string literals in C. You should not modify them
because the standard says you should not, not because they are const
qualified.

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

[CBFalconer]

Jack Klein wrote:

"Mark A. Odell" <od*******@hotm ail.com> wrote in comp.lang.c:
.... snip ...

the reason should jump out at you (hint: note the 'const' keyword).

Nope, just plain wrong. There is absolutely no const keyword
implied in any way for string literals in C. You should not modify
them because the standard says you should not, not because they are
const qualified.

However you are well advised to define those strings as const
anyhow, because then you will probably get an alert from the
compiler if you misuse them. gcc has a -Wconstant-strings
available to do it automatically.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Cocy]

Dear folks,

Thank you for you guys comment.

Ok, I understood that I can't safely modify the
strings after I've initialized it because it's
"const".
The page
http://www.eskimo.com/~scs/C-faq/q1.32.html
says like "the string may be stored in read-only
memory", and I suppose this explains the string
may be stored in "the memory area which is
assigned to be read-only", by the expression
"read-only memory".

If it is correct (I don't care whether it's correct
or not), where is the area?, who decide the area?
I mean does the compiler tell to someone (OS?) like
"please let this program use this meory area as to
be const"? or does OS decide like "Oh, you, the
program, I'll keep the string into the safety area
so that you can't modify later"?
In other word, does the compiler knows where the
"read-only memory", or only OS knows where it is?
(is only OS able to decide where it is)?

And where is the area actually? Is is this area so
called "heap"?
I guess I have to learn a lot to fully understand
my question. Is there any source to learn about
these things? (please don't say "take the class in
school" :-) Does the assembly code tell me those
stuffs?

Thanks and Best Regards,
Cocy

[Jonathan Adams]

In article <55************ **************@ posting.google. com>,
ku*********@hot mail.com (Cocy) wrote:

Dear folks,

Thank you for you guys comment.

Ok, I understood that I can't safely modify the
strings after I've initialized it because it's
"const".
The page
http://www.eskimo.com/~scs/C-faq/q1.32.html
says like "the string may be stored in read-only
memory", and I suppose this explains the string
may be stored in "the memory area which is
assigned to be read-only", by the expression
"read-only memory".

If it is correct (I don't care whether it's correct
or not), where is the area?, who decide the area?
I mean does the compiler tell to someone (OS?) like
"please let this program use this meory area as to
be const"? or does OS decide like "Oh, you, the
program, I'll keep the string into the safety area
so that you can't modify later"?
In other word, does the compiler knows where the
"read-only memory", or only OS knows where it is?
(is only OS able to decide where it is)?
Generally, the compiler and linker have almost complete control over
this, and merely leave instructions for the OS and dynamic linker to
follow.
And where is the area actually? Is is this area so
called "heap"?
On UNIX, it's typically the "read-only data segment", or ".rodata".
During linking, this will usually be merged (along with ".init",
".fini", and any number of other read-only segments) with "text"
segment into a "program header" covering all of the read-only loadable
segments. You can view this by using (on linux):

% objdump -x /path/to/binary

or, (on Solaris):

% elfdump /path/to/binary

Look for "Program Header" and "Section", and start lining things up.
I guess I have to learn a lot to fully understand
my question. Is there any source to learn about
these things? (please don't say "take the class in
school" :-) Does the assembly code tell me those
stuffs?

It's more the linker -- _Linkers and Loaders_ by John R. Levine (ISBN
1558604960) is the best book I've run across for these sorts of details.
You could also google for documentation on ELF (Executable Linking
Format), which is the UNIX standard format.

Cheers,
- jonathan