Почему это делается для выхода из цикла на некоторых платформах, а не на других?

Ошибка между этими фрагментами кода:

int array[10],i;

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

array[i]=0;

Так как array имеет только 10 элементов, в последней итерации array[10] = 0; происходит переполнение буфера. Переполнение буфера UNDEFINED BEHAVIOR, что означает, что они могут отформатировать ваш жесткий диск или заставить демонов вылететь из вашего носа.

Это довольно часто, когда все переменные стека располагаются рядом друг с другом. Если i находится там, где array[10] записывается, тогда UB будет reset i до 0, что приведет к завершенному циклу.

Чтобы исправить, измените условие цикла на i < 10.

В чем должен быть последний прогон цикла, вы пишете в array[10], но в массиве всего 10 элементов, пронумерованных от 0 до 9. Спецификация языка C говорит, что это "поведение undefined", На практике это означает, что ваша программа попытается записать в int -размерную часть памяти, которая находится сразу после array в памяти. То, что происходит тогда, зависит от того, что на самом деле лежит там, и это зависит не только от операционной системы, но и от того, что такое компилятор, от параметров компилятора (таких как настройки оптимизации), архитектуры процессора, окружающего кода и т.д. Это может даже варьироваться от исполнения до исполнения, например из-за рандомизации адресного пространства (вероятно, не на этом примере игрушек, но это происходит в реальной жизни). Некоторые возможности включают в себя:

• Местоположение не использовалось. Цикл нормально завершается.
• Местоположение было использовано для чего-то, что имело значение 0. Цикл заканчивается нормально.
• Местоположение содержит адрес возврата функции. Цикл завершается нормально, но затем программа выходит из строя, потому что пытается перейти к адресу 0.
• Местоположение содержит переменную i. Цикл никогда не заканчивается, потому что i перезапускается с 0.
• В этом месте находится другая переменная. Цикл заканчивается нормально, но затем происходят "интересные" события.
• Местоположение является недопустимым адресом памяти, например. потому что array находится справа в конце страницы виртуальной памяти, а следующая страница не отображается.
• Демоны вылетают из вашего носа. К счастью, большинству компьютеров не хватает необходимого оборудования.

То, что вы наблюдали в Windows, заключалось в том, что компилятор решил поместить переменную i сразу после массива в память, поэтому array[10] = 0 закончил присвоение i. На Ubuntu и CentOS компилятор не разместил там i. Почти все реализации C группируют локальные переменные в памяти, в стек памяти, с одним основным исключением: некоторые локальные переменные могут быть помещены целиком в регистры. Даже если переменная находится в стеке, порядок переменных определяется компилятором, и это может зависеть не только от порядка в исходном файле, но и от их типов (чтобы избежать потери памяти для ограничений выравнивания, которые оставят дыры), на их именах, на некоторое хэш-значение, используемое во внутренней структуре данных компилятора и т.д.

Если вы хотите узнать, что решил ваш компилятор, вы можете сказать ему, чтобы показать вам код ассемблера. О, и научитесь расшифровывать ассемблер (это проще, чем писать). С 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 непосредственно перед массивом; вы перезаписали бы i, если бы вам пришлось писать на array[-1]. Если вы измените 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 - но он не потрудился выделить любую память для array или генерировать код для установки его элементов, потому что он заметил, что ни один из элементов никогда не используется.

Чтобы сделать этот пример более информативным, позвольте гарантировать, что назначения массива выполняются, предоставляя компилятору что-то, что он не может оптимизировать. Легкий способ сделать это - использовать массив из другого файла - из-за отдельной компиляции компилятор не знает, что происходит в другом файле (если он не оптимизирует время ссылки, которое 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

Теперь массив находится в стеке, 44 байта сверху. Что насчет i? Он нигде не появляется! Но счетчик циклов хранится в регистре rbx. Это не точно i, а адрес array[i]. Компилятор решил, что, поскольку значение i никогда не использовалось напрямую, не было смысла выполнять арифметику, чтобы вычислить, где хранить 0 во время каждого цикла цикла. Вместо этого этот адрес является переменной цикла, а арифметика для определения границ выполнялась частично во время компиляции (умножить 11 итераций на 4 байта на элемент массива, чтобы получить 44) и частично во время выполнения, но раз и навсегда до начала цикла ( выполнить вычитание, чтобы получить начальное значение).

Даже в этом очень простом примере мы видели, как изменяются параметры компилятора (включайте оптимизацию) или изменяете что-то незначительное (array[i] до array[9-i]) или даже изменяете что-то явно не связанное (добавление вызова к use_array) может существенно повлиять на то, что делает исполняемая программа, сгенерированная компилятором. Оптимизация компилятора может многое сделать, что может показаться неинтуитивным для программ, вызывающих поведение undefined. Поэтому поведение undefined остается полностью undefined. Когда вы немного отклоняетесь от треков, в реальных программах, очень сложно понять взаимосвязь между тем, что делает код и что он должен был сделать, даже для опытных программистов.

В отличие от Java, C не выполняет проверку границ массива, т.е. там нет ArrayIndexOutOfBoundsException, задача убедиться, что индекс массива действителен, остается программисту. Выполнение этого с целью приводит к undefined поведению, все может случиться.

Для массива:

int array[10]

действительны только в диапазоне от 0 до 9. Однако вы пытаетесь:

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

доступ array[10] здесь, измените условие на i < 10

У вас есть нарушение границ, а на платформах, не связанных с завершением, я считаю, что вы случайно не устанавливаете i в ноль в конце цикла, чтобы он начинался снова.

array[10] недействителен; он содержит 10 элементов, array[0] через array[9], а array[10] - 11-й. Ваш цикл должен быть записан для остановки до 10 следующим образом:

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

Где земли array[10] определены реализацией, и забавно, на двух ваших платформах, он приземляется на i, который эти платформы, по-видимому, выкладываются непосредственно после array. i устанавливается на ноль, и цикл продолжается навсегда. Для других платформ i может располагаться до array, или array может иметь некоторое дополнение после него.

Вы объявляете int array[10] означает array имеет индекс 0 до 9 (всего 10 целых элементов, которые он может удерживать). Но следующий цикл,

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

будет цикл 0 до 10 означает 11 время. Следовательно, когда i = 10 он переполнит буфер и вызовет Undefined Behavior.

Итак, попробуйте следующее:

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

или,

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

Это undefined в array[10] и дает поведение undefined, как описано выше. Подумайте об этом так:

У меня есть 10 предметов в моей продуктовой тележке. Это:

0: Ящик с зерном
1: Хлеб
2: Молоко
3: Pie
4: Яйца
5: Торт
6: 2 л соды
7: Салат
8: Бюргерса
9: Мороженое

cart[10] является undefined и может давать исключение за пределы в некоторых компиляторах. Но, по-видимому, нет. Очевидный 11-й элемент - это элемент не на самом деле в корзине. 11-й пункт указывает на то, что я собираюсь назвать, "объект полтергейста". Он никогда не существовал, но он был там.

Почему некоторые компиляторы дают i индекс array[10] или array[11] или даже array[-1] из-за вашего утверждения инициализации/объявления. Некоторые компиляторы интерпретируют это как:

• "Выделите 10 блоков int для array[10] и еще один int блок. , чтобы упростить его, поставить их рядом друг с другом."
• То же, что и раньше, но переместите его на два или два места, так что array[10] не указывает на i.
• Сделайте то же самое, что и раньше, но выделите i в array[-1] (потому что индекс массива не может или не должен быть отрицательным), или выделите его в совершенно другом месте, потому что ОС может обработайте его, и он безопаснее.

Некоторые компиляторы хотят, чтобы все ускорилось, а некоторые компиляторы предпочитают безопасность. Все о контексте. Например, если я разрабатывал приложение для древней ОС BREW (ОС базового телефона), это не заботило бы о безопасности. Если бы я развивался для iPhone 6, то он мог быстро работать независимо от того, что мне нужно, и мне нужно сделать упор на безопасность. (Серьезно, вы читали руководства Apple App Store или читали о развитии Swift и Swift 2.0?)

Поскольку вы создали массив размером 10, для условия цикла должно быть следующее:

int array[10],i;

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

В настоящее время вы пытаетесь получить доступ к неназначенному местоположению из памяти с помощью array[10] и это вызывает поведение undefined. Undefined поведение означает, что ваша программа будет вести себя неопределенно, поэтому она может давать разные выходы в каждом исполнении.

Ну, компилятор C традиционно не проверяет границы. Вы можете получить ошибку сегментации в случае, если вы ссылаетесь на местоположение, которое не "принадлежит" вашему процессу. Однако локальные переменные выделяются в стеке и в зависимости от способа выделения памяти область, находящаяся за пределами массива (array[10]), может принадлежать сегменту памяти процесса. Таким образом, не возникает ловушка отказов сегментации, и это то, что вы, похоже, испытываете. Как указывали другие, это поведение undefined в C, и ваш код может считаться неустойчивым. Поскольку вы изучаете C, вам лучше привыкнуть проверять границы вашего кода.

Помимо возможности того, что память может быть выложена так, чтобы попытка записи на a[10] фактически перезаписывала i, также было бы возможно, что оптимизирующий компилятор может определить, что тест цикла не может быть достигнут со значением i больше десяти без кода, который первым обратился к несуществующему элементу массива a[10].

Поскольку попытка доступа к этому элементу будет иметь поведение undefined, у компилятора не будет никаких обязательств в отношении того, что программа могла бы выполнить после этой точки. Более конкретно, поскольку компилятор не обязан генерировать код для проверки индекса цикла в любом случае, когда он может быть больше десяти, он не обязан генерировать код для его проверки; он мог вместо этого предположить, что тест <=10 всегда будет иметь значение true. Обратите внимание, что это было бы правдой, даже если код читал бы a[10], а не записывал его.

Когда вы повторяете прошлое i==9, вы назначаете ноль "элементам массива", которые фактически расположены после массива, поэтому вы перезаписываете некоторые другие данные. Скорее всего, вы перезаписываете переменную i, которая находится после a[]. Таким образом, вы просто reset переменной i равны нулю и, таким образом, перезапустите цикл.

Вы можете обнаружить это самостоятельно, если вы напечатали i в цикле:

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

вместо

      printf("test \n");

Конечно, этот результат сильно зависит от распределения памяти для ваших переменных, что, в свою очередь, зависит от компилятора и его настроек, поэтому он обычно Undefined Behavior - почему результаты на разных машинах или разные операционные системы или разные компиляторы могут отличаться.

Я предлагаю что-то, что я нахожу выше:

Попробуйте назначить массив [i] = 20;

Я предполагаю, что это должно повредить код везде.. (если вы держите я <= 10 или ll)

Если это произойдет, вы можете твердо решить, что ответы, указанные здесь, уже верны [ответ, связанный с памятью, топающей один для примера.]

ошибка в частичном массиве [10] w/c также является адресом я (int array [10], i;). когда array [10] установлен в 0, тогда я будет 0 w/c сбрасывает весь цикл и вызывает бесконечный цикл.   будет бесконечный цикл, если массив [10] находится между 0-10. Правильный цикл должен быть для (i = 0; я < 10; я ++) {...}           int array [10], i;           для (i = 0; я <= 10; я ++)           массив [I] = 0;

Здесь есть две вещи. Int я - это элемент массива, массив [10], как показано в стеке. Поскольку вы позволили индексированию фактически сделать массив [10] = 0, индекс цикла я не будет превышать 10. Сделайте его for(i=0; i<10; i+=1).

i ++ есть, поскольку K & R назвал бы его "плохим стилем". Он увеличивает я на размер i, а не 1. я ++ для математики указателя и я + = 1 для алгебры. Хотя это зависит от компилятора, это не является хорошим соглашением для переносимости.