Why printf prints a random value using the float and integer format specifier

Question

I wrote simple code on a 64 bit machine

int main() { printf("%d", 2.443); } 

So this is how the compiler will behave. It will identify the second argument as double, so it will push 8 bytes onto the stack, or perhaps just use registers for calls to access variables. %d expects a 4-byte integer value, so it prints some garbage.

Interestingly, the value is printed every time this program is executed. So what's going on? I expected it to print the same garbage value every time it is different.

Answer 1

This behavior is undefined, of course, for passing arguments that do not fit the format, so the language cannot tell us why the output is changing. We need to look at the implementation, what code it produces, and possibly the operating system.

My setting is different from yours,

Linux 3.1.10-1.16-desktop x86_64 GNU / Linux (openSuSE 12.1)

with gcc-4.6.2. But it looks like it’s reasonable to suspect the same mechanisms.

If you look at the generated assembly ( -O3 , out of habit), then the corresponding part ( main ) will be

 .cfi_startproc subq $8, %rsp # adjust stack pointer .cfi_def_cfa_offset 16 movl $.LC1, %edi # move format string to edi movl $1, %eax # move 1 to eax, seems to be the number of double arguments movsd .LC0(%rip), %xmm0 # move the double to the floating point register call printf xorl %eax, %eax # clear eax (return 0) addq $8, %rsp # adjust stack pointer .cfi_def_cfa_offset 8 ret # return 

If instead of double , I pass int , not many changes, but significantly

 movl $47, %esi # move int to esi movl $.LC0, %edi # format string xorl %eax, %eax # clear eax call printf 

I looked at the generated code for many variants of the types and number of arguments passed to printf , and sequentially, the first double arguments (or advanced float ) are passed to xmmN , N = 0, 1, 2 , and the integer ( int , char , long , regardless from r8d ) are transferred to esi , edx , ecx , r8d , r9d , and then on the stack.

Therefore, I dare to suggest that printf looks for the declared int in esi and prints everything that happens there.

Whether esi content is in any way predictable when nothing moves to main , and what they can mean, I have no idea.

Answer 2

This answer attempts to resolve some of the change options. This is the answer to Daniel Fisher's question and some comments on it.

Since I do not work with Linux, I cannot give a definitive answer. With a printf later in a large application there would be many sources of potential variation. At the beginning of a small application, there should be only a few.

Address space location randomization (ASLR) is one: the operating system deliberately randomly reorders some memory to prevent malware knowing which addresses to use. I do not know if this has Linux 3.4.4-2.

The other is environment variables. Shell environment variables are copied into the processes that it spawns (and are accessible through the getenv procedure). Some of them may change automatically, so they will have slightly different meanings. This is unlikely to directly affect what printf sees when it tries to use a missing integer argument, but there may be cascading effects.

There may be a shared library loader that starts either before calling main , or before calling printf . For example, if printf is in a shared library and not embedded in your executable, then calling printf will most likely result in a call to the stub procedure that calls the bootloader. The loader scans the shared library, finds the module containing printf , loads the module into the address space of the process, changes the stub so that it calls the recently loaded printf right in the future (instead of calling the loader), and calls printf . As you can imagine, this can be a fairly extensive process and includes, among other things, finding and reading files on disk (all directories for access to the shared library and shared library). It is possible that some caching or file operations on your system result in little behavior in the bootloader.

So far, I have endorsed the ASLR as the most likely candidate of the above. The last two are likely to be fairly stable; values ​​usually change sometimes rather than often. ASLR will change every time, and just leaving the address in the register is enough to explain the behavior of printf .

Here is an experiment: after the initial printf insert another printf using this code:

 printf("%d\n", 2.443); int a; printf("%p\n", (void *) &a); 

The second printf prints the address of a , which is most likely on the stack. Run the program two or three times and calculate the difference between the value printed by the first printf and the value printed by the second printf . (The second printf will most likely print in hexadecimal, so it would be convenient to change the first to "% x" to make it hexadecimal.) If the value printed by the second printf varies from run to run, then your program is experiencing ASLR. If the values ​​change from run to run, but the difference between them remains constant, then the value that printf occurred in the first printf is some address in your process that remains lying after the program was initialized.

If address a changes, but the difference does not remain constant, you can try changing int a; on static int a; to compare if the first value compares with the other part of your address space the best result.

Naturally, none of this is useful for writing reliable programs; this is just an educational question about how loading and initializing a program works.