segmentation fault ... SIGSEGV

[sunilkjin]

Hi,
What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).
Thanks
Slashdot
void main()
{
char *s="abcdexgh";
reverse(s);
printf("%s",s);
}

void reverse( char *s)
{

char *q,*p;
int j;
char t;
j=strlen(s);
--j;
q= s + j;
for(p=s; p < q; ++p,--q)
{
t=*p;
*p=*q;
*q=t;
}

}

 

[Pierre L.]

What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).

It's not.

void main()
{
char *s="abcdexgh";

Your compiler chose to store the string in non writable memory
as it's a constant. Hence, if you try to modify it
(as your reverse function does it), a sigsegv is raised.

Try to replace this line with a:
char *s = strdup("abcdexgh");

reverse(s);
printf("%s",s);

Add a:
free(s);
when you no longer need s.

 

[mark_bluemel]

Hi,
What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).

No it doesn't...

char *s="abcdexgh";

s points to the first character of a string literal. This is not
guaranteed to be in writable memory (indeed, it should ideally not be).

char s[] = "abcdexgh";

would work.

I'm sure this is an FAQ.

 

[mark_bluemel]

It's not.


Your compiler chose to store the string in non writable memory
as it's a constant. Hence, if you try to modify it
(as your reverse function does it), a sigsegv is raised.

Try to replace this line with a:
char *s = strdup("abcdexgh");

Can I be the first to say "off-topic", as strdup() isn't part of the
standard for C?

 

[Richard Tobin]

What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).

char *s="abcdexgh";

That string may not be modified. Use

char s[] = "abcdexgh";

-- Richard

 

[David T. Ashley]

Hi,
What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).

<SNIP>

In addition to what the other posters have mentioned, there were several
compilers in history (and they may still exist) that automatically combined
identical string literals, so that:

char *s = "ABC";
char *p = "Das Wetter is schoen";
char *q = "ABC";

would automatically get s and q the same address.

In addition, it is not unknown that a function will return the address of an
internal static string literal (for reference only, but not modification).

Those things really were not made to be modfied ...

 

[Chris Dollin]

Hi,
What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).

void main()

Not portable: don't do that. (Declare it as `int main()` in this case.)

You are NOT ALLOWED to write into string literals. What happens is
NOT DEFINED. So DO NOT DO THAT.

(fx:music)

What shall we do with the drunken sailor,
(fx:repeat 2)
Earl-y in the morn-ing.

 

[Barry]

Can I be the first to say "off-topic", as strdup() isn't part of the
standard for C?

I am probably not going to be the first to PLONK mark_bluemel.

 

[Chris Dollin]

I am probably not going to be the first to PLONK mark_bluemel.

Why on Earth would you want to plonk him for what he said above?
(It is, after all, true that `strdup` isn't Standard C.)

 

[Barry]

Why on Earth would you want to plonk him for what he said above?
(It is, after all, true that `strdup` isn't Standard C.)

Why on Earth would you assume my decision to PLONK
someonewas based on a single message or the part of the
message that was relevant to C?

 

[Richard Tobin]

Why on Earth would you want to plonk him for what he said above?
(It is, after all, true that `strdup` isn't Standard C.)

[/QUOTE]

Why on Earth would you assume my decision to PLONK
someonewas based on a single message or the part of the
message that was relevant to C?

Because you did it in a reply to that message without mentioning
any other context.

-- Richard

 

[Ingo Menger]

No it doesn't...


s points to the first character of a string literal. This is not
guaranteed to be in writable memory (indeed, it should ideally not be).

Indeed.
Ideally, the compiler also should warn when someone tries to pass a
const char* value to an unknown function.

 

[Barry]

Why on Earth would you assume my decision to PLONK
someonewas based on a single message or the part of the
message that was relevant to C?

Because you did it in a reply to that message without mentioning
any other context.
[/QUOTE]

Doesn't " I am probably not going to be the first," posted on
clc imply the context?

 

[Dave Hansen]

Indeed.
Ideally, the compiler also should warn when someone tries to pass a
const char* value to an unknown function.

What's an "unknown function"?

Note that s is not a const char*. Neither is the string literal. So
there's nothing for the compiler to warn about. A good lint might pick
it out for you.

If the string literal _was_ a const char*, the warning should come on
the initialization rather than the function call.

-=Dave

 

[Richard Tobin]

Because you did it in a reply to that message without mentioning
any other context.

[/QUOTE]

Doesn't " I am probably not going to be the first," posted on
clc imply the context?

It didn't when I read it.

-- Richard

 

[Keith Thompson]

What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...). [...]
char *s="abcdexgh";
reverse(s);

[...]

The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've just asked
question 8.5.

 

[Keith Thompson]

I am probably not going to be the first to PLONK mark_bluemel.

Usually if someone publicly plonks someone else, the intent is for
other readers to understand the reason for doing so. I've read this
entire thread, and I have no clue why you've chosen to plonk
mark_bluemel; I suspect others are equally bewildered. You might wish
to explain your reasoning. If you'd rather not, I suggest that next
time you add someone to your killfile for whatever reason (which
you're perfectly entitled to do), there's no real need to announce it
to the world.

 

[CBFalconer]

It's not.


Your compiler chose to store the string in non writable memory
as it's a constant. Hence, if you try to modify it
(as your reverse function does it), a sigsegv is raised.

Try to replace this line with a:
char *s = strdup("abcdexgh");

Faulty advice. Ignoring the other errors in the OP's code, the
replacement should be:

char s[] = "abcdexgh";

 

[Chris Dollin]

Why on Earth would you assume my decision to PLONK
someonewas based on a single message or the part of the
message that was relevant to C?

Because you chose to comment on that single message and did
not allude to any other of Mark's messages.

(fx:voice One.)

 

[Peter Shaggy Haywood]

Groovy hepcat (e-mail address removed) was jivin' on 11 Jan 2007 06:41:51
-0800 in comp.lang.c.
segmentation fault ... SIGSEGV's a cool scene! Dig it!

What is wrong with the reverse function, gives a segmentatiion
violation. I think it is relates to data alignment.(4 bytes ...).

void main()

int main(void)

{
char *s="abcdexgh";
reverse(s);
printf("%s",s);

Undefined behaviour. Can you guess why, hmm? Well, I'll tell you.
Like all variadic functions, printf() needs a prototype, otherwise any
use of it causes undefined behaviour, according to the standard. Also,
since you have not declared the return type of printf(), the (C90)
compiler assumes it returns an int. In this case that just happens to
be correct. By sheer luck you have avoided more undefined behaviour.
But it won't always be the case. (See below.) (A C99 compiler will at
least diagnose this, and likely refuse to compile it.)
And just think; you could've avoided this problem simply by
including stdio.h.

}

void reverse( char *s)
{

char *q,*p;
int j;
char t;
j=strlen(s);

Undefined behaviour. Can you guess why, hmm? Well, I'll tell you.
Since there is no declaration of strlen() in scope, the (C90) compiler
thinks it returns an int. (A C99 compiler will at least diagnose this,
and likely refuse to compile it.) When strlen() actually returns a
size_t, an implementation defined unsigned integer type, the compiler
attempts to interpret that as a signed int. Different types may be
returned in different places. And they may have different sizes. But
in either case, they have different representations.
And just think; you could've avoided this problem simply by
including string.h.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?