当你遍历i==9时，你把0赋给了实际上位于数组后面的“数组项”，所以你覆盖了一些其他数据。最可能的情况是，你重写了i变量，它位于a[]之后。这样，您只需将i变量重置为零，从而重新启动循环。

如果你在循环中输出i，你自己就会发现:

      printf("test i=%d\n", i);

而不仅仅是

      printf("test \n");

当然，这个结果很大程度上取决于变量的内存分配，而这又取决于编译器及其设置，所以它通常是Undefined Behavior——这就是为什么在不同的机器或不同的操作系统或不同的编译器上的结果可能不同。

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.

如果你想知道你的编译器决定做什么，你可以告诉它给你看汇编代码。哦，还要学习破译汇编程序(这比编写汇编程序容易)。在GCC(以及其他一些编译器，特别是Unix世界)中，传递选项-S来生成汇编代码而不是二进制代码。例如，下面是使用GCC在amd64上编译循环的汇编程序片段，使用优化选项-O0(无优化)，并手动添加注释:

.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

在这里，变量i位于堆栈顶部下方52个字节，而数组则从堆栈顶部下方48个字节开始。所以这个编译器刚好把i放在数组的前面;如果你碰巧写数组[-1]，你会覆盖I。如果你将array[i]=0改为array[9-i]=0，你将在这个特定的平台上使用这些特定的编译器选项得到一个无限循环。

现在让我们用gcc -O1编译您的程序。

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

那是短!编译器不仅拒绝为i分配堆栈位置——它只存储在寄存器ebx中——而且它也没有为数组分配任何内存，或者生成代码来设置它的元素，因为它注意到没有一个元素被使用过。

为了使这个例子更有说服力，让我们确保数组赋值是通过向编译器提供它无法优化的东西来执行的。一种简单的方法是使用来自另一个文件的数组——由于单独编译，编译器不知道在另一个文件中发生了什么(除非它在链接时进行优化，而gcc - o0或gcc - o1不会进行优化)。创建一个源文件use_array.c，包含

void use_array(int *array) {}

并将源代码更改为

#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;
}

编译和

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

这次汇编代码看起来像这样:

    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.

与Java不同，C不做数组边界检查，也就是说，没有ArrayIndexOutOfBoundsException异常，确保数组索引有效的工作留给了程序员。故意这样做会导致未定义的行为，任何事情都可能发生。

对于数组:

int array[10]

索引只在0到9的范围内有效。然而，你正试图:

for (i = 0; i <=10 ; i++)

访问数组[10]，将条件更改为I < 10

当你遍历i==9时，你把0赋给了实际上位于数组后面的“数组项”，所以你覆盖了一些其他数据。最可能的情况是，你重写了i变量，它位于a[]之后。这样，您只需将i变量重置为零，从而重新启动循环。

如果你在循环中输出i，你自己就会发现:

      printf("test i=%d\n", i);

而不仅仅是

      printf("test \n");

当然，这个结果很大程度上取决于变量的内存分配，而这又取决于编译器及其设置，所以它通常是Undefined Behavior——这就是为什么在不同的机器或不同的操作系统或不同的编译器上的结果可能不同。

Well, C compiler traditionally does not check for bounds. You can get a segmentation fault in case you refer to a location that does not "belong" to your process. However, the local variables are allocated on stack and depending on the way the memory is allocated, the area just beyond the array (array[10]) may belong to the process' memory segment. Thus, no segmentation fault trap is thrown and that is what you seem to experience. As others have pointed out, this is undefined behavior in C and your code may be considered erratic. Since you are learning C, you are better off getting into the habit of checking for bounds in your code.

除了内存布局的可能性之外，写入[10]的尝试实际上会覆盖i，优化编译器也可能会确定，如果代码没有首先访问不存在的数组元素[10]，则i值大于10时无法达到循环测试。

Since an attempt to access that element would be undefined behavior, the compiler would have no obligations with regard to what the program might do after that point. More specifically, since the compiler would have no obligation to generate code to check the loop index in any case where it might be greater than ten, it would have no obligation to generate code to check it at all; it could instead assume that the <=10 test will always yield true. Note that this would be true even if the code would read a[10] rather than writing it.