Why does this for loop exit on some platforms and not on others?

On my laptop running Ubuntu 14.04, this code does not break it runs to completion. On my school's computer running CentOS 6.6, it also runs fine. On Windows 8.1, the loop never terminates.

What is more strange is when I edit the conditional of the for loop to: i <= 11, the code only terminates on my laptop running Ubuntu. CentOS and Windows never terminates.

You've just discovered memory stomping. You can read more about it here: What is a “memory stomp”?

When you allocate int array[10],i;, those variables go into memory (specifically, they're allocated on the stack, which is a block of memory associated with the function). array[] and i are probably adjacent to each other in memory. It seems that on Windows 8.1, i is located at array[10]. On CentOS, i is located at array[11]. And on Ubuntu, it's in neither spot (maybe it's at array[-1]?).

Try adding these debugging statements to your code. You should notice that on iteration 10 or 11, array[i] points at i.

#include <stdio.h> int main() {   int array[10],i;    printf ("array: %p, &i: %p\n", array, &i);   printf ("i is offset %d from array\n", &i - array);  for (i = 0; i <=11 ; i++)   {     printf ("%d: Writing 0 to address %p\n", i, &array[i]);     array[i]=0; /*code should never terminate*/   }   return 0; } 

The bug lies between these pieces of code:

int array[10],i;for (i = 0; i <=10 ; i++)array[i]=0;

Since array only has 10 elements, in the last iteration array[10] = 0; is a buffer overflow. Buffer overflows are UNDEFINED BEHAVIOR, which means they might format your hard drive or cause demons to fly out of your nose.

It is fairly common for all stack variables to be laid out adjacent to each other. If i is located where array[10] writes to, then the UB will reset i to 0, thus leading to the unterminated loop.

To fix, change the loop condition to i < 10.

In what should be the last run of the loop,you write to array[10], but there are only 10 elements in the array, numbered 0 through 9. The C language specification says that this is “undefined behavior”. What this means in practice is that your program will attempt to write to the int-sized piece of memory that lies immediately after array in memory. What happens then depends on what does, in fact, lie there, and this depends not only on the operating system but more so on the compiler, on the compiler options (such as optimization settings), on the processor architecture, on the surrounding code, etc. It could even vary from execution to execution, e.g. due to address space randomization (probably not on this toy example, but it does happen in real life). Some possibilities include:

• The location wasn't used. The loop terminates normally.
• The location was used for something which happened to have the value 0. The loop terminates normally.
• The location contained the function's return address. The loop terminates normally, but then the program crashes because it tries to jump to the address 0.
• The location contains the variable i. The loop never terminates because i restarts at 0.
• The location contains some other variable. The loop terminates normally, but then “interesting” things happen.
• The location is an invalid memory address, e.g. because array is right at the end of a virtual memory page and the next page isn't mapped.
• Demons fly out of your nose. Fortunately most computers lack the requisite hardware.

What you observed on Windows was that the compiler decided to place the variable i immediately after the array in memory, so array[10] = 0 ended up assigning to i. On Ubuntu and CentOS, the compiler didn't place i there. Almost all C implementations do group local variables in memory, on a memory stack, with one major exception: some local variables can be placed entirely in registers. Even if the variable is on the stack, the order of variables is determined by the compiler, and it may depend not only on the order in the source file but also on their types (to avoid wasting memory to alignment constraints that would leave holes), on their names, on some hash value used in a compiler's internal data structure, etc.

If you want to find out what your compiler decided to do, you can tell it to show you the assembler code. Oh, and learn to decipher assembler (it's easier than writing it). With GCC (and some other compilers, especially in the Unix world), pass the option -S to produce assembler code instead of a binary. For example, here's the assembler snippet for the loop from compiling with GCC on amd64 with the optimization option -O0 (no optimization), with comments added manually:

.L3:    movl    -52(%rbp), %eax           ; load i to register eax    cltq    movl    $0, -48(%rbp,%rax,4)      ; set array[i] to 0    movl    $.LC0, %edi    call    puts                      ; printf of a constant string was optimized to puts    addl    $1, -52(%rbp)             ; add 1 to i.L2:    cmpl    $10, -52(%rbp)            ; compare i to 10    jle     .L3

Here the variable i is 52 bytes below the top of the stack, while the array starts 48 bytes below the top of the stack. So this compiler happens to have placed i just before the array; you'd overwrite i if you happened to write to array[-1]. If you change array[i]=0 to array[9-i]=0, you'll get an infinite loop on this particular platform with these particular compiler options.

Now let's compile your program with gcc -O1.

    movl    $11, %ebx.L3:    movl    $.LC0, %edi    call    puts    subl    $1, %ebx    jne     .L3

That's shorter! The compiler has not only declined to allocate a stack location for i — it's only ever stored in the register ebx — but it hasn't bothered to allocate any memory for array, or to generate code to set its elements, because it noticed that none of the elements are ever used.

To make this example more telling, let's ensure that the array assignments are performed by providing the compiler with something it isn't able to optimize away. An easy way to do that is to use the array from another file — because of separate compilation, the compiler doesn't know what happens in another file (unless it optimizes at link time, which gcc -O0 or gcc -O1 doesn't). Create a source file use_array.c containing

void use_array(int *array) {}

and change your source code to

#include <stdio.h>void use_array(int *array);int main(){  int array[10],i;  for (i = 0; i <=10 ; i++)  {    array[i]=0; /*code should never terminate*/    printf("test \n");  }  printf("%zd \n", sizeof(array)/sizeof(int));  use_array(array);  return 0;}

Compile with

gcc -c use_array.cgcc -O1 -S -o with_use_array1.c with_use_array.c use_array.o

This time the assembler code looks like this:

    movq    %rsp, %rbx    leaq    44(%rsp), %rbp.L3:    movl    $0, (%rbx)    movl    $.LC0, %edi    call    puts    addq    $4, %rbx    cmpq    %rbp, %rbx    jne     .L3

Now the array is on the stack, 44 bytes from the top. What about i? It doesn't appear anywhere! But the loop counter is kept in the register rbx. It's not exactly i, but the address of the array[i]. The compiler has decided that since the value of i was never used directly, there was no point in performing arithmetic to calculate where to store 0 during each run of the loop. Instead that address is the loop variable, and the arithmetic to determine the boundaries was performed partly at compile time (multiply 11 iterations by 4 bytes per array element to get 44) and partly at run time but once and for all before the loop starts (perform a subtraction to get the initial value).

Even on this very simple example, we've seen how changing compiler options (turn on optimization) or changing something minor (array[i] to array[9-i]) or even changing something apparently unrelated (adding the call to use_array) can make a significant difference to what the executable program generated by the compiler does. Compiler optimizations can do a lot of things that may appear unintuitive on programs that invoke undefined behavior. That's why undefined behavior is left completely undefined. When you deviate ever so slightly from the tracks, in real-world programs, it can be very hard to understand the relationship between what the code does and what it should have done, even for experienced programmers.