char * string = "Hello"; memory address space

Question

This board seems filled with these type of questions and I did go through a few of them, but I still am confused regarding the difference between those two:

char string[] = "Hello"; 
char * string2 = "hello";

Now,

char string[] = "Hello"; 

... is an array and is allocated 6 consecutive memory address spaces where the characters are stored, including \0 at the end.

%p of &string shows memory address 0x7fffbcabce90. %p of string shows the same memory address 0x7fffbcabce90. %p of string[1] shows 0x7fffbcabce90 + typeof(char), so 0x7fffbcabce91. etc.

char * string2 = "hello";

... is a pointer to char type and it points to memory address of the first character of the string (h).

%p of &string2 shows memory address 0x7fffbcabce88. %p of string2 shows a different memory address of 0x400ca8. %p of string2[1] shows 0x400ca8 + sizeof(char), so 0x400ca9.

My questions are: what is this memory address range (0x400000)? Is it the reason why I can't modify the string characters like so?:

string[1] = 'c';   //that works
string2[1] = 'c';  //not working

Thanks!

Edit: typo (%string2 => &string2)

Edit2: As was explained to me, the keyword is string literal.

char * string2[] = "Hello"; 

... is a pointer to a string literal. Here's a thread where R Samuel Klatchko explains where are stored literals in memory:

String literals: Where do they go?

Answer 1

char string[] = "Hello"; 

declares a null-terminated array of char and initialises it to contain "Hello\0".

char * string2 = "hello";

declares a pointer to char and initialises it to point to a string literal.

Modifying a string literal invokes undefined behaviour. It's common for compilers to put string literals in read only memory, and it would seem that is what your compiler is doing. Not all compilers will do that – the key point is that modifying string literals invokes undefined behaviour.

There's little to be gained from looking at the actual values of the pointers in your program. The read-only address is close to 0x00400000 because, I presume, you are running on Windows and that's the default load address of an executable module. But nothing says that a module must load there. A library won't.

---

Let's look at:

printf("%p %p %p %p", string1, &string1, string2, &string2);

In this expression, string1 decays to a pointer, and so gives the same output as &string1. And string2 is a pointer, and &string2 is that pointer's address.

Answer 2

The layout of the virtual address space of a process is generally arranged by the linker and the loader. Generally, the memory of a process can be organized into types including:

• The “text” section, which contains the instructions that are executed.
• Read-only data, which contains values that are read but are not modified or executed.
• Initialized data, which is set to initial values at program start-up but may be modified during program execution.
• Uninitialized data, which the program needs for work space but does not need to be set to any particular values at program start-up.

There are various embellishments and refinements of the types of memory, but the above suffice for a general orientation.

Separating memory of different types is important for performance and for security, including:

• Because the text and read-only data sections are not modified during program execution, they can be shared if the same program is executed more than once simultaneously. Each time the program is run, the operating system can map these portions of the virtual address spaces of different processes to the same physical memory. Every process will have the same data in these sections.
• Because the non-text sections should never be executed as instructions, they can be marked as non-executable. This means the hardware will cause an exception if an attempt is made to execute them, which should only occur if there is a bug or an attacker causes the program to execute things it should not.

The operating system does not keep track of every individual byte in the address space of a process. Most hardware does not support it, and it would require too much data. Instead, there is a minimum amount of memory, called a page, that is used. Whenever memory is marked executable or not-executable, writable or not writable, it must be done in units of whole pages. 4096 bytes is a typical page size, but it varies from system to system.

What you are seeing in the difference addresses of a char string[] = "Hello"; and the char *string2 = "Hello"; is that the read-only data of the string literal "Hello" is being put into a different page than the modifiable array initialized with "Hello".

There is nothing magic about the address 0x400000, except that it was chosen as the place for read-only data in the system you are using. It could be elsewhere. There may even be linker options to move it to an address of your choosing. What is important is merely that it is separate from the modifiable data.

While the linker is reading object modules and organizing them to form one executable, it concatenates the same types of segments from different object modules. That is, it takes the text segments from each module and puts them together into one large text segment. It takes the read-only data segments from each module and puts them together into one large data segment. And so on. This is simply more efficient than leaving each object module’s segments as separate pieces—if one object module used 2.5 pages for read-only data and another used 1.5 pages, then putting them together uses just 4 pages, whereas leaving them separate with fragments of pages unused would use 5 pages. (Some special segments might be processed in different ways than concatenation.)

Additionally, although memory can be managed in units of pages, there may be benefits to grouping larger amounts of memory of the same type together. If you mark an entire megabyte to have the same attributes, the operating system might use less data to keep track of it than if you marked pages individually. This could be part of the reason that the linker sets aside a large amount of program address space for a certain type of memory. (I am speculating; I am not familiar with the current motivations and design for the specific operating system you are using.)

Answer 3

Because an array is not a pointer.

char string[] = "Hello"; 

declares string to be an array and initializes it with the characters of the string on the RHS. This array is not declared as const, so you can modify its elements.

Of course, the array begins in memory where its first element lies (well, at least on any sensible implementation I know of, but this is not a requirement), so naturally string (which decays into a pointer to the first element) has the same numerical pointer value as &string, which is a pointer to an array itself. They have different types, though (pointer-to-char and pointer-to-array-of-6-chars).

This is how it looks like in memory:

+-----+-----+-----+-----+-----+-----+
| 'H' | 'e' | 'l' | 'l' | 'o' | \0  |
+-----+-----+-----+-----+-----+-----+
^
+-- pointer to first element
|
+-- also: pointer to array

On the other hand,

char *string2 = "Hello";

is wrong: here you are assigning a pointer (a pointer that the array "Hello" decays into) of read-only characters to a pointer-to-non-const. This should be

const char *string2 = "Hello";

Now string2 is a pointer, it has a separate storage from that of its pointed value (the first element of the array). So naturally its address is different from that of the first element of the array (which it points to). And it's not initialized with the array. The array (the string literal) is (presumably) placed in read-only memory; the Standard says it's undefined behavior to attempt to modify its contents.

This is how the construct with the pointer is laid out in memory:

+-----+            +-----+-----+-----+-----+-----+-----+
|  p  | ---------> | 'H' | 'e' | 'l' | 'l' | 'o' | \0  |
+-----+            +-----+-----+-----+-----+-----+-----+
^                  ^
+- adddress of     +- address of the array (and the first element)
   the pointer        This is the **value** that is stored in p
   itself
   (completely
   unrelated to
   the address
   of the array)