200

I am interested in where string literals get allocated/stored.

I did find one intriguing answer here, saying:

Defining a string inline actually embeds the data in the program itself and cannot be changed (some compilers allow this by a smart trick, don't bother).

But, it had to do with C++, not to mention that it says not to bother.

I am bothering. =D

So my question is where and how is my string literal kept? Why should I not try to alter it? Does the implementation vary by platform? Does anyone care to elaborate on the "smart trick?"

Improve this question
0

8 Answers 8

Reset to default
150

A common technique is for string literals to be put in "read-only-data" section which gets mapped into the process space as read-only (which is why you can't change it).

It does vary by platform. For example, simpler chip architectures may not support read-only memory segments so the data segment will be writable.

Rather than try to figure out a trick to make string literals changeable (it will be highly dependent on your platform and could change over time), just use arrays:

char foo[] = "...";

The compiler will arrange for the array to get initialized from the literal and you can modify the array.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

You do have to be careful about buffer overflow when using arrays for mutable strings, though - simply writing a string longer than the array length (e.g. foo = "hello" in this case) can cause unintended side-effects... (assuming you're not re-allocating memory with new or something)
Does when using array string goes in stack or elsewhere ?
Can't we use char *p = "abc"; to make mutable strings as differently said by @ChrisCooper
@asn in that case p will be a pointer to a string literal, and the behavior is still platform-dependent. This will work with MSVC on Windows, but not GCC or Clang on Linux.
84

Why should I not try to alter it?

Because it is undefined behavior. Quote from C99 N1256 draft 6.7.8/32 "Initialization":

EXAMPLE 8: The declaration

char s[] = "abc", t[3] = "abc";

defines "plain" char array objects s and t whose elements are initialized with character string literals.

This declaration is identical to

char s[] = { 'a', 'b', 'c', '\0' }, t[] = { 'a', 'b', 'c' };

The contents of the arrays are modifiable. On the other hand, the declaration

char *p = "abc";

defines p with type "pointer to char" and initializes it to point to an object with type "array of const char" with length 4 whose elements are initialized with a character string literal. If an attempt is made to use p to modify the contents of the array, the behavior is undefined.

Where do they go?

GCC 4.8 x86-64 ELF Ubuntu 14.04:

  • char s[]: stack
  • char *s:
    • .rodata section of the object file
    • the same segment where the .text section of the object file gets dumped, which has Read and Exec permissions, but not Write

Program:

#include <stdio.h> int main() { char *s = "abc"; printf("%s\n", s); return 0; }

Compile and decompile:

gcc -ggdb -std=c99 -c main.c objdump -Sr main.o

Output contains:

 char *s = "abc"; 8: 48 c7 45 f8 00 00 00 movq $0x0,-0x8(%rbp) f: 00 c: R_X86_64_32S .rodata

So the string is stored in the .rodata section.

Then:

readelf -l a.out

Contains (simplified):

Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000000704 0x0000000000000704 R E 200000 Section to Segment mapping: Segment Sections... 02 .text .rodata

This means that the default linker script dumps both .text and .rodata into a segment that can be executed but not modified (Flags = R E). Attempting to modify such a segment leads to a segfault in Linux.

If we do the same for char[]:

 char s[] = "abc";

we obtain:

17: c7 45 f0 61 62 63 00 movl $0x636261,-0x10(%rbp)

so it gets stored in the stack (relative to %rbp), and we can of course modify it.

Improve this answer

1 Comment

Modern toolchains put .rodata in a separate ELF segment so it can be read-only without exec, hardening more against ROP / Spectre gadgets by keeping bytes out of executable pages when they don't need to be executable. But yes, string literals still go into .rodata which gets mapped into read-only pages, except when used as initializers to non-const arrays.
61

There is no one answer to this. The C and C++ standards just say that string literals have static storage duration, any attempt at modifying them gives undefined behavior, and multiple string literals with the same contents may or may not share the same storage.

Depending on the system you're writing for, and the capabilities of the executable file format it uses, they may be stored along with the program code in the text segment, or they may have a separate segment for initialized data.

Determining the details will vary depending on the platform as well -- most probably include tools that can tell you where it's putting it. Some will even give you control over details like that, if you want it (e.g. gnu ld allows you to supply a script to tell it all about how to group data, code, etc.)

Improve this answer

5 Comments

I find it unlikely that the string data would be stored directly in the .text segment. For really short literals, I could see the compiler generating code such as movb $65, 8(%esp); movb $66, 9(%esp); movb $0, 10(%esp) for the string "AB", but the vast majority of the time, it will be in a non-code segment such as .data or .rodata or the like (depending on whether or not the target supports read-only segments).
If string literals are valid for the entire duration of the program, even during the destruction of static objects then is it valid to return const reference to a string literal? Why this program shows runtime error see ideone.com/FTs1Ig
@AdamRosenfield: If you're bored sometime, you might want to look at (for one example) the legacy UNIX a.out format (e.g., freebsd.org/cgi/…). One thing you should quickly notice is that it only supports one data segment, which is always writable. So if you want read-only string literals, essentially the only place they can go is the text segment (and yes, at the time linkers frequently did exactly that).
Why is this? Why don't put them in the stack as any other local variable?
@Carlitos_30: As a stack-based local variable, they'd still need to be initialized from something to hold the correct contents. So if you want a local variable with the correct contents, you use char foo[] = "whatever";, and you'll get a local array of char--that's usually initialized from an actual string literal somewhere.
24

FYI, just backing up the other answers:

The standard: ISO/IEC 14882:2003 says:

2.13. String literals

  1. [...]An ordinary string literal has type “array of n const char” and static storage duration (3.7)

  2. Whether all string literals are distinct (that is, are stored in nonoverlapping objects) is implementation- defined. The effect of attempting to modify a string literal is undefined.

Improve this answer

4 Comments

Helpful information, but notice link is for C++, whereas question is tanged to c
confirmed #2 in 2.13. With -Os option (optimize for size), gcc overlaps string literals in .rodata.
The corresponding parts in C11 and C17 are 6.4.5 paragraphs 6 and 7. The main difference is that the array elements have type char in C and const char in C++. The array is still considered non-modifiable in C even though its type is not explicitly const-qualified.
@IanAbbott useful - if you have time, please make this an answer!
18

gcc makes a .rodata section that gets mapped "somewhere" in address space and is marked read only,

Visual C++ (cl.exe) makes a .rdata section for the same purpose.

You can look at the output from dumpbin or objdump (on Linux) to see the sections of your executable.

E.g.

>dumpbin vec1.exe Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file vec1.exe File Type: EXECUTABLE IMAGE Summary 4000 .data 5000 .rdata <-- here are strings and other read-only stuff. 14000 .text
Improve this answer

3 Comments

I can’t see how to get disassembly of the rdata section with objdump.
@user2284570, that's because that section doesn't contain assembly. It contains data.
Just a matter to get more readable output. I mean I would like to get strings inlined with disassembly instead of address to those sections. (hem you knowprintf("some null terminated static string");instead ofprintf(*address);in C)
5

It depends on the format of your executable. One way to think about it is that if you were assembly programming, you might put string literals in the data segment of your assembly program. Your C compiler does something like that, but it all depends on what system you're binary is being compiled for.

Improve this answer

Comments

3

String literals are frequently allocated to the read-only memory, making them immutable. However, in some compilers modification is possible by a "smart trick"..And the smart trick is by "using character pointer pointing to memory"..remember some compilers, may not allow this..Here is demo 

char *tabHeader = "Sound"; *tabHeader = 'L'; printf("%s\n",tabHeader); // Displays "Lound"
Improve this answer

Comments

0

As this might differ from compiler to compiler, the best way is to filter an object dump for the searched string literal:

objdump -s main.o | grep -B 1 str

where -s forces objdump to display the full contents of all sections, main.o is the object file, -B 1 forces grep to also print one line before the match (so that you can see the section name) and str is the string literal you're searching for.

With gcc on a Windows machine, and one variable declared in main like

char *c = "whatever";

running

objdump -s main.o | grep -B 1 whatever

returns

Contents of section .rdata: 0000 77686174 65766572 00000000 whatever....
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.