Why are string literals const?

Solution 1:

There are a couple of different reasons.

One is to allow storing string literals in read-only memory (as others have already mentioned).

Another is to allow merging of string literals. If one program uses the same string literal in several different places, it's nice to allow (but not necessarily require) the compiler to merge them, so you get multiple pointers to the same memory, instead of each occupying a separate chunk of memory. This can also apply when two string literals aren't necessarily identical, but do have the same ending:

char *foo = "long string";
char *bar = "string";

In a case like this, it's possible for bar to be foo+5 (if I'd counted correctly).

In either of these cases, if you allow modifying a string literal, it could modify the other string literal that happens to have the same contents. At the same time, there's honestly not a lot of point in mandating that either -- it's pretty uncommon to have enough string literals that you could overlap that most people probably want the compiler to run slower just to save (maybe) a few dozen bytes or so of memory.

By the time the first standard was written, there were already compilers that used all three of these techniques (and probably a few others besides). Since there was no way to describe one behavior you'd get from modifying a string literal, and nobody apparently thought it was an important capability to support, they did the obvious: said even attempting to do so led to undefined behavior.

Solution 2:

It's undefined behaviour to modify a literal because the standard says so. And the standard says so to allow compilers to put literals in read only memory. And it does this for a number of reasons. One of which is to allow compilers to make the optimisation of storing only one instance of a literal that is repeated many times in the source.

Solution 3:

I believe you ask about the reason why literals are placed in read-only memory, not about technical details of linker doing this and that or legal details of a standard forbidding such and such.

When modification of string literals works, it leads to subtle bugs even in the absence of string merging (which we have reasons to disallow if we decided to permit modification). When you see code like

char *str="Hello";
.../* some code, but str and str[...] are not modified */
printf("%s world\n", str);

it's a natural conclusion that you know what's going to be printed, because str (and its content) were not modified in a particular place, between initialization and use.

However, if string literals are writable, you don't know it any more: str[0] could be overwritten later, in this code or inside a deeply nested function call, and when the code is run again,

char *str="Hello";

won't guarantee anything about the content of str anymore. As we expect, this initialization is implemented as moving the address known in link time into a place for str. It does not check that str contains "Hello" and it does not allocate a new copy of it. However, we understand this code as resetting str to "Hello". It's hard to overcome this natural understanding, and it's hard to reason about the code where it is not guaranteed. When you see an expression like x+14, what if you had to think about 14 being possibly overwritten in other code, so it became 42? The same problem with strings.

That's the reason to disallow modification of string literals, both in the standard (with no requirement to detect the failure early) and in actual target platforms (providing the bonus of detecting potential bugs).

I believe that many attempts to explain this thing suffer from the worst kind of circular reasoning. The standard forbids writing to literals because the compiler can merge strings, or they can be placed in read-only memory. They are placed in read-only memory to catch the violation of the standard. And it's valid to merge literals because the standard forbids... is it a kind of explanation you asked for?

Let's look at other languages. Common Lisp standard makes modification of literals undefined behaviour, even though the history of preceding Lisps is very different with the history of C implementations. That's because writable literals are logically dangerous. Language standards and memory layouts only reflect that fact.

Python language has exactly one place where something resembling "writing to literals" can happen: parameter default values, and this fact confuses people all the time.

Your question is tagged C++, and I'm unsure of its current state with respect to implicit conversion to non-const char*: if it's a conversion, is it deprecated? I expect other answers to provide a complete enlightenment on this point. As we talk of other languages here, let me mention plain C. Here, string literals are not const, and an equivalent question to ask would be why can't I modify string literals (and people with more experience ask instead, why are string literals non-const if I can't modify them?). However, the reasoning above is fully applicable to C, despite this difference.