Why are the memory addresses of string literals so different from others', on Linux?

I noticed that string literals have very different addresses in memory than other constants and variables (Linux OS): they have many leading zeroes (not printed).

Example:

const char *h = "Hi";
int i = 1;
printf ("%p\n", (void *) h);
printf ("%p\n", (void *) &i);

Output:

0x400634
0x7fffc1ef1a4c

I know they are stored in the .rodata part of the executable. Is there a special way the OS handles it afterwards, so the literals end up in a special area of memory (with leading zeroes)? Are there any advantages of that memory location or is there something special about it?

Here's how process memory is laid out on Linux (from http://www.thegeekstuff.com/2012/03/linux-processes-memory-layout/):

The .rodata section is a write-protected subsection of the Initialized Global Data block. (A section which ELF executables designate .data is its writable counterpart for writable globals initialized to nonzero values. Writable globals initialized to zeros go to the .bss block. By globals here I mean global variables and all static variables regardless of placement.)

The picture should explain the numerical values of your addresses.

If you want to investigate further, then on Linux you can inspect the /proc/$pid/maps virtual files which describe the memory layout of running processes. You won't get the reserved (starting with a dot) ELF section names, but you can guess which ELF section a memory block originated from by looking at its memory protection flags. For example, running

$ cat /proc/self/maps #cat's memory map

gives me

00400000-0040b000 r-xp 00000000 fc:00 395465                             /bin/cat
0060a000-0060b000 r--p 0000a000 fc:00 395465                             /bin/cat
0060b000-0060d000 rw-p 0000b000 fc:00 395465                             /bin/cat
006e3000-00704000 rw-p 00000000 00:00 0                                  [heap]
3000000000-3000023000 r-xp 00000000 fc:00 3026487                        /lib/x86_64-linux-gnu/ld-2.19.so
3000222000-3000223000 r--p 00022000 fc:00 3026487                        /lib/x86_64-linux-gnu/ld-2.19.so
3000223000-3000224000 rw-p 00023000 fc:00 3026487                        /lib/x86_64-linux-gnu/ld-2.19.so
3000224000-3000225000 rw-p 00000000 00:00 0
3000400000-30005ba000 r-xp 00000000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30005ba000-30007ba000 ---p 001ba000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30007ba000-30007be000 r--p 001ba000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30007be000-30007c0000 rw-p 001be000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30007c0000-30007c5000 rw-p 00000000 00:00 0
7f49eda93000-7f49edd79000 r--p 00000000 fc:00 2104890                    /usr/lib/locale/locale-archive
7f49edd79000-7f49edd7c000 rw-p 00000000 00:00 0
7f49edda7000-7f49edda9000 rw-p 00000000 00:00 0
7ffdae393000-7ffdae3b5000 rw-p 00000000 00:00 0                          [stack]
7ffdae3e6000-7ffdae3e8000 r--p 00000000 00:00 0                          [vvar]
7ffdae3e8000-7ffdae3ea000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

The first r-xp block definitely came from .text (executable code), the first r--p block from .rodata, and the following rw-- blocks from .bss and .data. (In between the heap and the stack block are blocks loaded from dynamically linked libraries by the dynamic linker.)

---

Note: To comply with the standard, you should cast the int* for "%p" to (void*) or else the behavior is undefined.

That's because string literals have static storage duration. That is, they will live during the whole program. Such variables may be stored in a special memory location which is neither on the so called heap nor the stack. Hence the difference in addresses.

Remember that where a pointer is is different from where a pointer points to. A more realistic (apples-to-apples) comparison would be

printf ("%p\n", (void *) &h);
printf ("%p\n", (void *) &i);

I suspect you will find that h and p have similar addresses. Or, another more-realistic comparison would be

static int si = 123;
int *ip = &si;
printf ("%p\n", (void *) h);
printf ("%p\n", (void *) ip);

I suspect you'll find that h and ip point to a similar region of memory.

Consider that literals are read-only variables and as well, there is a concept of a literal pool. What the literal pool is is a collection of the program's unique literals, where duplicate constants are discarded as references are merged into one.

There is one literal pool for each source, and depending on the sophistication of the link / bind program, literal pools can be placed next to each other to create one .rodata.

There is also no guarantee that the literal pool is read-only protected. Language though compiler designs treat it as so.

Consider my code fragment. I could have

*const char cp="hello world";
*const char cp1="hello world";

The good compiler will recognize that within that source code, the read-only literals cp, cp1,are pointing to identical strings, and will make cp1 point to cp's literal, discarding the second one.

One more point. The literal pool may be a multiple of 256bytes or different value. If the pool data is less than 256 bytes, the slack will be padded with hex zeros.

Different compilers, follow common development standards, permitting a module compiled with C, to be linked with a module compiled with assembly language or other language. The two literal pools are placed consecutively in .rodata.

printf ("%p\n", h); // h is the address of "Hi", which is in the rodata or other segments of the application.
printf ("%p\n", &i); // I think "i" is not a global variable, so &i is in the stack of main. The stack address is by convention in the top area of the memory space of the process.