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.

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:

Code:

---

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

---

or:

Code:

---

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

---

Quote:

---

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?

Quote:

---

Originally Posted by brewbuck

I believe it's -fwritable-strings.

---

You're right.

Quote:

---

why would you modify a string literal?

---

Laziness? :D

Quote:

---

Originally Posted by itsme86

You're right.


Laziness? :D

---

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

I'm not saying I do it (I don't). I was just trying to expand on your terse (mostly correct) response to the OP.

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?

Quote:

---

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.

Don't confuse "constants" with the "const" type qualifier. They don't mean exactly the same thing in C. And yes, it can be confusing.

Quote:

---

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

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

Segfaults are a function of the OS, not the language.

Or consider an embedded platform, where the strings are stored in ROM. You can try as much as you want to modify the string. It won't happen of course (it's ROM), but neither is it likely to cause any kind of exception.

So you have 3 possible outcomes, all of which are valid
- it works,
- it doesn't work,
- you die trying.

Which is why you need to learn the language from understanding good quality reference material, not from reverse engineered observations of a couple of compilers.

Quote:

---

Originally Posted by itsme86

You're right.


Laziness? :D

---

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

Quote:

---

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.

Hi,

Thank You all very much. This thread helped clear a lot of my doubts. :)