Thread: segfault with gcc, but not with TC

Consider the following program.

Code:

#include <stdio.h>
int main()
{
char *a = "Hello";
a[2] = 'a';
return 0;
}

This program compiles fine, without any error/warning messages. On TC it even executes okay(if I print the string pointed to by a, it prints Healo), however with gcc on execution it gives a segmentation fault.
Now I know that TC and gcc are different in some ways like :
1) TC uses 16 bit pointers while gcc uses 32 bit pointers
2) gcc conforms to the ansi version of C, more that TC
I may be wrong about these differences but this is what I know.

Whatever the differences may be, I could not understand why it gives the segfault error with gcc.
Help needed.

String literals are not writable on most platforms.

Originally Posted by itsme86

gcc does have (or at least used to) the compile option --writable-strings, but it's better to just do it correctly in the first place:

I believe it's -fwritable-strings. It's something I'd NEVER recommend using -- why would you modify a string literal?

Originally Posted by itsme86

You're right.


Laziness?

It's a terrible idea. It forces the compiler to turn off string merging. It makes your program larger (potentially much, much larger)

Thank You all, that solved it completely. But now I have one more question. I tried the following code :

Code:

#include <stdio.h>
int main()
{
const int a=10;
int *b = &a;
*b=20;
printf("%d\n", a);
return 0;
}

when I compiled it, I got the following warning:

Code:

koodoo@knapsacker:~$ gcc prog.c -o prog
prog.c: In function `main':
prog.c:5: warning: initialization discards qualifiers from pointer target type
koodoo@knapsacker:~$

But when I executed it, I got the following result:

Code:

koodoo@knapsacker:~$ ./prog
20
koodoo@knapsacker:~$

How do I explain this now?

Originally Posted by koodoo

But when I executed it, I got the following result:

Code:

koodoo@knapsacker:~$ ./prog
20
koodoo@knapsacker:~$

The "const" tells the compiler not to allow changes to the variable. However, you can take its address and cast it into a pointer to non-const. The compiler rightly complains when you do this, but it doesn't PREVENT you from doing it.

Altering a string literal, and casting away the const-ness of a pointer, are both awful things to do.

k, I fully agree that they are awfull thing to do.
But doesn't the second scenario in a way contradict the first one as far as C is concerned ?.
Shouldn't there be more consistency in the way C handles the constants.

I mean if it stores the string literal in a segment that's marked readonly, shouldn't the constant integer a be stored in the same segment so that it again gives a segfault at runtime?

It's just a thought.

Originally Posted by koodoo

Shouldn't there be more consistency in the way C handles the constants.

I mean if it stores the string literal in a segment that's marked readonly, shouldn't the constant integer a be stored in the same segment so that it again gives a segfault at runtime?

It's just a thought.

You're right on the money. This is widely considered to be a deficiency of the C language. But remember that C was originally designed as a "portable assembler" intended primarily for implementing system-level software. At the system level, there are often legitimate reasons to do weird things like this.

In C++, the meaning of "const" has been somewhat altered to align it more with the concept of a "constant."

Originally Posted by itsme86

You're right.


Laziness?

if you suddenly have to support code that abuses this the option comes in handy

Originally Posted by Salem

> shouldn't the constant integer a be stored in the same segment so that it again gives a segfault at runtime?
Except your 'TC' isn't running on a protected OS. Even if TC puts the strings into the text segment, that still won't stop you from modifying the strings.
16-bit DOS knows nothing about such things, no matter where you trample in memory.

Just a quick side note, Salem: Borland/Inprise have resurrected the Turbo name for some of their recent compilers/development environments. Those compilers are 32 bit.