以下C char数组存储实现背后的原因是什么？

Question

What is the implementation reason behind the following char array implementation?

char *ch1 = "Hello"; // Read-only data
/* if we try ch1[1] = ch1[2]; 
we will get **Seg fault** since the value is stored in 
the constant code segment */

char ch2[] = "World"; // Read-write data
/* if we try ch2[1] = ch2[2]; will work. */

According to the book Head first C (page 73,74), the ch2[] array is stored both in constant code segment but also in the function stack. What is the reason behind duplicating both in code and stack memory space? Why the value can be kept only in stack if it is not read-only data?

Answer 1

First, let's clear something up. String literals are not necessarily read-only data, it's just that it's undefined behaviour to try and change them.

It doesn't necessarily have to crash, it may work just fine. But, being undefined behaviour, you shouldn't rely on it if you want you code to run in another implementation, another version of the same implementation, or even next Wednesday.

This may well stem from a time before standards were in place (the original ANSI/ISO mandate was to codify existing practice rather than create a new language). In many implementations, strings would share space for efficiency, such as the code:

char *good = "successful";
char *bad = "unsuccessful";

resulting in:

good---------+
bad--+       |
     |       |
     V       V
   | u | n | s | u | c | c | e | s | s | f | u | l | \0 |

Hence, if you changed one of the characters in good , it would also change bad .

The reason you can do it with something like:

char indifferent[] = "meh";

is that, while good and bad point to a string literal, that statement actually creates a character array big enough to hold "meh" and then copies the data into it ¹ . The copy of the data can be freely changed.

In fact the C99 rationale document explicitly cites this as one of the reasons:

String literals are not required to be modifiable. This specification allows implementations to share copies of strings with identical text, to place string literals in read-only memory, and to perform certain optimizations.

But regardless as to why, the standard is quite clear on the what. From C11 6.4.5 String literals :

7/ It is unspecified whether these arrays are distinct provided their elements have the appropriate values. If the program attempts to modify such an array, the behavior is undefined.

For the latter case, this is covered in 6.7.6 Declarators and 6.7.9 Initialisation .

---

¹ Though it's worth noting the the normal "as if" rules apply here (as long as an implementation acts as if it's following the standard, it can do what it pleases).

In other words, if the implementation can detect that you never try to change the data, it can quite happily bypass the copy and use the original.

Answer 2

We will get Seg fault since the value is stored in the constant code segment

This is false: your program crashes because it receives a signal indicating a segment violation ( SIGSEGV ) which, by default, causes the program to terminate. But this is not the primary reason. Modifying a string literal is undefined behavior , whether it's stored in read-only segments or not, which is much wider than you think.

array is stored both in constant code segment but also in the function stack.

This is an implementation detail and shouldn't concern you: as far as ISO C is concerned, those statements make no sense. This also means it could be implemented differently.

When you

 char ch2[] = "World";

"World" , which is a string literal, is copied into ch2 , something you would end up doing if you used malloc and pointers. Now, why is that copied?

One reason for this may be that it's something you would expect. If you could modify such string literal, what if another part of the code referred to it and expected to have that value? Having shared string literals is efficient because you can share them across your program and saves space.

By copying it, you have your own copy of the string ( you "own" it) and you can modify it as you will.

Quoting "Rationale for American National Standard for Information Systems Programming Language C"

String literals are specied to be unmodiable. This specication allows implementations to share copies of strings with identical text, to place string literals in read-only memory, and perform certain optimizations. However, string literals do not have the type array of const char, in order to avoid the problems of pointer type checking, particularly with library functions, since assigning a pointer to const char to a plain pointer to char is not valid.

Answer 3

This is only a partial answer with a counter-example to a claim that a string literal is stored in a read only memory:

int main() {
   char a[]="World";
   printf("%s", a);
}

gcc -O6 -S cc

.LC0:
    .string "%s"                  ;; String literal stored as expected
                                  ;; in read-only area within code
    ...
    movl    $1819438935, (%rsp)   ;; First four bytes in "worl"
    movw    $100, 4(%rsp)         ;; next to bytes in "d\0"
    call    printf
    ...

Here only the semantics of the concept literal is implemented; the literal "world\\0" doesn't even exist.

In practice only when the string literals are long enough, an optimizing compiler will choose to memcpy data from the literal pool to stack, requiring the existence of the literal as null terminating string.

The semantics of char *ch1 = "Hello"; OTOH requires that there exists a linear array somewhere, whose address can be assigned to the pointer ch1 .