C String Literals Are Lvalues

C values come in two types: lvalues and rvalues. The intuitive way to think of this is that lvalues are the things allowed on the left side of expressions, and rvalues are the things allowed on the right side. For instance, consider the following two assignment statements:

int x;
x = 1;  // OK
1 = x;  // Error

The first assignment statement is legal because x is an lvalue and 1 is an rvalue, and everything appears in the right place. The second assignment statement is illegal because it has an rvalue on the left-hand side. In fact, if you try to compile this code you'll get a cryptic error explaining this:

$ cc x.c
x.c: In function ‘main’:
x.c:3:5: error: lvalue required as left operand of assignment
   1 = x;

Literals like 7, true, and 1.0f are normally rvalues. This means that literals can only appear on the right side of an assignment expression. However, there's one corner case: string literals (e.g. "hello") are actually lvalues!

To understand why, we need to understand what the type of a string literal is in C. You might assume that a string literal has type char * or const char *, but that's wrong. In C, a string literal has type char []. There are a few different reasons why this makes sense, but one way to think about this is how the sizeof operator is supposed to work on a string literal. Consider the following C program; what do you think will be printed to the screen?

#include <stdio.h>

int main() {
  printf("sizeof hello = %zd\n", sizeof "hello");
  return 0;

This program actually prints sizeof hello = 6, because 6 is the length of the string "hello", including the terminating null byte. If string literals were pointer types, then this would just print the size of a pointer, which would be 4 for a 32-bit system or 8 for a 64-bit system. Since string literals are actually arrays, the sizeof operator can instead print the actual size of the array, which is the string length in this case. This is very convenient, since it allows compile-time substitution of the size of string literals, which arises frequently.

Another reason that string literals should be array types, rather than pointer types, is that it lets them be used in array contexts. For instance, you can write code like this, which only works if string literals are arrays:

// Unusual function taking a fixed-sized character array.
void foo(char s[6]) {
    // do something with s

int main() {
    return 0;

In general, array types in C will automatically decay into pointer types if necessary. For instance, the parameter for strlen() is a const pointer:

// Takes a pointer type, not an array.
size_t strlen(const char *s);

When passing a string literal like "hello" to strlen(), the value decays from a char [] to a const char *. This works because arrays decay into pointer types, and non-const values can be used in const contexts. Thus an expression like strlen("hello") is perfectly valid, even though "hello" is really an array, not a pointer.

Arrays are always lvalues (since they must have an address in memory), and thus C string literals are also lvalues.

Mutating String Literals

The following program is legal according to the C spec, but is logically invalid:

// Legal, but naughty.
int main() {
  "foo"[0] = 0;
  return 0;

When compiling this program, GCC gives a warning ("warning: assignment of read-only location"), but still produces an executable. The executable terminates with a segmentation fault when run. What actually happens though, when we run a program like this? GDB shows the following disassembly when the program crashes:

(gdb) disas
Dump of assembler code for function main:
   0x0000000000400487 <+0>:	push   %rbp
   0x0000000000400488 <+1>:	mov    %rsp,%rbp
=> 0x000000000040048b <+4>:	movb   $0x0,0x9e(%rip)        # 0x400530
   0x0000000000400492 <+11>:	mov    $0x0,%eax
   0x0000000000400497 <+16>:	pop    %rbp
   0x0000000000400498 <+17>:	retq
End of assembler dump.

This is showing us that the compiler is trying to write a single zero byte to memory location 0x400530. We can ask GDB what's mapped at this memory location, but the output isn't too useful:

(gdb) info proc mappings
process 29646
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x401000     0x1000        0x0 /home/evan/a.out
            ... many more lines ...

This isn't useful because we see the range that 0x400530 is mapped at, but not what permissions that range is mapped with. To see the permissions, we need to look at /proc:

$ cat /proc/29646/maps
00400000-00401000 r-xp 00000000 fd:02 20710675                /home/evan/a.out
... more lines ...

This shows that memory address 0x400530 is mapped with permissions r-xp, which means that the memory location is readable and executable, but not writable. In other words, the compiler has generated valid code, but the linker has arranged the memory layout such that the generated code will segfault. This is a weird idiosyncrasy of C: the language standard generally pretends like linkers don't exist, even though in practice linking has a big effect on the runtime behavior of programs.

String Literals In C++

As a minor (but important) point of trivia, the type of string literals in C++ is different from C. In C, a string literal has type char []. In C++, a string literal has type const char [].

The fact that C++ makes a string literal into a const value improves things somewhat. For instance, if you compile the previous example with a C++ compiler, you should get a compiler error (rather than a warning), since mutating const values is strictly prohibited. As always you can easily circumvent these checks with type casts or aliased pointers, so you still need to exercise caution.

For completeness, I should also add that while C++ has lvalues and rvalues, it further subdivides them into a much more complicated value category zoo, with exotic types like glvalues and xvalues.