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.c
gcc -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.
i
is stored right after the end ofarray
, and you are overwriting it witharray[10]=0;
. This might not be the case in an optimised build on the same platform, which may storei
in a register and never refer to it in memory at all. – paddy