У який момент циклу переповнення цілих чисел стає невизначеною поведінкою?

Це приклад для ілюстрації мого запитання, яке включає набагато складніший код, який я не можу розмістити тут.

#include <stdio.h>
int main()
{
    int a = 0;
    for (int i = 0; i < 3; i++)
    {
        printf("Hello\n");
        a = a + 1000000000;
    }
}

Ця програма містить невизначену поведінку на моїй платформі, оскільки aвона переповнюється в 3-му циклі.

Чи це спричиняє невизначену поведінку всієї програми або лише після того, як насправді відбувається переповнення ? Чи може компілятор потенційно працювати, що a буде переповнюватися , тому він може оголосити весь цикл невизначеного і не турбувати , щоб запустити printfs , навіть якщо вони все відбудуться до переливу?

_{(Позначені C та C ++, хоча і відрізняються, бо мене цікавлять відповіді для обох мов, якщо вони різні.)}

Якщо вас цікавить чисто теоретична відповідь, стандарт С ++ дозволяє невизначену поведінку "подорожувати у часі":

[intro.execution]/5: Відповідна реалізація, що виконує добре сформовану програму, повинна виробляти таку ж спостережувану поведінку, як одне з можливих виконання відповідного екземпляра абстрактної машини з тією ж програмою та однаковим входом. Однак, якщо будь-яке таке виконання містить невизначену операцію, цей Міжнародний стандарт не встановлює вимог до реалізації, що виконує цю програму з цим входом (навіть щодо операцій, що передують першій невизначеній операції)

Таким чином, якщо ваша програма містить невизначену поведінку, то поведінка всієї вашої програми невизначена.

Спочатку дозвольте мені виправити заголовок цього запитання:

Невизначена поведінка не є (зокрема) сферою виконання.

Невизначена поведінка впливає на всі етапи: компіляцію, зв’язування, завантаження та виконання.

Деякі приклади, щоб це закріпити, майте на увазі, що жоден розділ не є вичерпним:

• компілятор може припустити, що частини коду, які містять невизначену поведінку, ніколи не виконуються, і, отже, припустити, що шляхи виконання, які призвели б до них, є мертвим кодом. Подивіться, що кожен програміст на C повинен знати про невизначену поведінку не хто інший, як Кріс Латтнер.
• лінкер може припустити, що за наявності кількох визначень слабкого символу (розпізнаного за іменем), всі визначення ідентичні завдяки Правилу одного визначення
• завантажувач (якщо ви використовуєте динамічні бібліотеки) може припустити те саме, вибравши таким чином перший знайдений символ; це зазвичай (ab) використовується для перехоплення дзвінків за допомогою LD_PRELOADхитрощів на Unix
• виконання може не вдатися (SIGSEV), якщо ви використовуєте звисаючі вказівники

Це те, що так страшно щодо невизначеної поведінки: майже неможливо заздалегідь передбачити, яка саме поведінка відбуватиметься, і це прогнозування слід переглядати при кожному оновленні ланцюжка інструментів, що лежить в основі ОС, ...

Я рекомендую переглянути це відео Майкла Спенсера (розробник LLVM): CppCon 2016: Мій маленький оптимізатор: Невизначена поведінка - це магія .

Агресивно оптимізуючий компілятор C або C ++, націлений на 16 біт, intбуде знати, що поведінка при додаванні 1000000000до intтипу невизначена .

Обидва стандарти дозволяють робити все, що завгодно, що може включати видалення всієї програми, залишаючи int main(){}.

Але як щодо великих ints? Я ще не знаю компілятора, який би це робив (і я не є експертом у розробці компілятора C і C ++ будь-якими способами), але я думаю, що колись компілятор, орієнтований на 32-бітну версію intабо більше, зрозуміє, що цикл нескінченна ( iне змінюється) і тому aв кінцевому підсумку переповнення. Отже, ще раз, він може оптимізувати вихід до int main(){}. Суть, яку я намагаюся сказати тут, полягає в тому, що в міру того, як оптимізація компілятора стає поступово більш агресивною, все більше і більше невизначених конструкцій поведінки проявляються несподівано.

Той факт, що ваш цикл нескінченний, сам по собі не визначений, оскільки ви пишете на стандартний вивід у тілі циклу.

Технічно, за стандартом С ++, якщо програма містить невизначену поведінку, поведінка всієї програми, навіть під час компіляції (ще до того, як програма буде навіть виконана), невизначена.

На практиці, оскільки компілятор може припустити (як частина оптимізації), що переповнення не відбудеться, принаймні поведінка програми на третій ітерації циклу (припускаючи 32-розрядну машину) буде невизначеною, хоча це ймовірно, ви отримаєте правильні результати до третьої ітерації. Однак, оскільки поведінка всієї програми технічно невизначена, ніщо не заважає програмі генерувати абсолютно неправильний результат (включаючи відсутність вихідних даних), збій під час виконання в будь-який момент під час виконання або навіть невдачу компіляції (оскільки невизначена поведінка поширюється на час компіляції).

Невизначена поведінка надає компілятору більше можливостей для оптимізації, оскільки вони усувають певні припущення щодо того, що повинен робити код. При цьому програми, які спираються на припущення, що стосуються невизначеної поведінки, не гарантовано працюватимуть належним чином. Таким чином, ви не повинні покладатися на якусь конкретну поведінку, яка вважається невизначеною відповідно до стандарту C ++.

Щоб зрозуміти, чому невизначена поведінка може «подорожувати у часі», як адекватно висловився @TartanLlama , давайте подивимось на правило «як би»:

1.9 Виконання програми

¹ Семантичні описи в цьому міжнародному стандарті визначають параметризовану недетерміновану абстрактну машину. Цей міжнародний стандарт не встановлює вимог щодо структури відповідних реалізацій. Зокрема, їм не потрібно копіювати або наслідувати структуру абстрактної машини. Швидше, відповідні реалізації вимагають імітувати (лише) спостережувану поведінку абстрактної машини, як пояснено нижче.

Завдяки цьому ми могли б розглядати програму як "чорний ящик" із входом і виходом. Вхідними даними можуть бути користувацькі дані, файли та багато іншого. Результатом є "спостережувана поведінка", згадана у стандарті.

Стандарт визначає лише відображення між входом і виходом, нічого іншого. Він робить це, описуючи "приклад чорного ящика", але прямо говорить, що будь-який інший чорний ящик з тим самим відображенням є однаково дійсним. Це означає, що вміст чорної скриньки не має значення.

З огляду на це, не мало б сенсу стверджувати, що невизначена поведінка відбувається в певний момент. У зразку реалізації чорного ящика ми могли б сказати, де і коли це відбувається, але фактично чорний ящик може бути чимось зовсім іншим, тому ми не можемо сказати, де і коли це відбувається. Теоретично, компілятор міг, наприклад, вирішити перерахувати всі можливі вхідні дані та попередньо обчислити отримані результати. Тоді невизначена поведінка могла б статися під час компіляції.

Невизначена поведінка - це відсутність відображення між входом і виходом. Програма може мати невизначену поведінку для одних входів, але визначена поведінка для інших. Тоді відображення між введенням і виходом просто неповне; є вхідні дані, для яких не існує зіставлення з вихідними даними.
Програма у питанні має невизначену поведінку для будь-якого вводу, тому відображення порожнє.

Припускаючи int, що 32-розрядна, невизначена поведінка трапляється на третій ітерації. Отже, якщо, наприклад, цикл був лише умовно доступний, або міг бути умовно завершений до третьої ітерації, не було б невизначеної поведінки, якщо третя ітерація фактично не досягнута. Однак у випадку невизначеної поведінки весь вихід програми є невизначеним, включаючи вихід, який є "в минулому" щодо виклику невизначеної поведінки. Наприклад, у вашому випадку це означає, що немає гарантії побачити 3 повідомлення "Привіт" у вихідних даних.

Відповідь TartanLlama правильна. Невизначена поведінка може статися в будь-який час, навіть під час компіляції. Це може здатися абсурдом, але це ключова особливість, яка дозволяє компіляторам робити те, що їм потрібно. Бути компілятором не завжди легко. Щоразу потрібно робити саме те, що сказано в специфікації. Однак іноді буває жахливо важко довести, що відбувається певна поведінка. Якщо ви пам'ятаєте проблему зупинки, досить тривіально розробити програмне забезпечення, для якого ви не можете довести, чи воно завершує або входить у нескінченний цикл, коли подається певний вхід.

Ми могли б зробити компілятори песимістами і постійно компілювати, боячись, що наступна інструкція може бути однією з таких зупиняючих проблем, як проблеми, але це не розумно. Натомість ми даємо компілятору пропуск: щодо цих тем "невизначеної поведінки" вони звільняються від будь-якої відповідальності. Невизначена поведінка складається з усіх видів поведінки, які є настільки витонченими, що у нас виникають проблеми з відокремленням їх від справді неприємно-підлих проблем зупинки та нічого іншого.

Є приклад, який я люблю публікувати, хоча, зізнаюся, я втратив джерело, тому доводиться перефразовувати. Це було з певної версії MySQL. У MySQL вони мали круговий буфер, який заповнювався наданими користувачем даними. Вони, звичайно, хотіли переконатися, що дані не переповнюють буфер, тому вони мали перевірку:

if (currentPtr + numberOfNewChars > endOfBufferPtr) { doOverflowLogic(); }

Це виглядає досить осудно. Однак що, якщо числоOfNewChars справді велике і переповнюється? Потім він обертається і стає покажчиком менше endOfBufferPtr, тому логіка переповнення ніколи не викликається. Тож вони додали другу перевірку, перед тим:

if (currentPtr + numberOfNewChars < currentPtr) { detectWrapAround(); }

Схоже, ви подбали про помилку переповнення буфера, так? Однак була подана помилка про те, що цей буфер переповнений у певній версії Debian! Ретельне дослідження показало, що ця версія Debian була першою, хто використав особливо криваву версію gcc. У цій версії gcc компілятор визнав, що currentPtr + numberOfNewChars ніколи не може бути меншим покажчиком, ніж currentPtr, оскільки переповнення покажчиків є невизначеною поведінкою! Цього було достатньо, щоб gcc оптимізував всю перевірку, і раптом ви не були захищені від переповнення буфера, хоча ви написали код для перевірки!

Це була специфічна поведінка. Все було законно (хоча з того, що я чув, gcc відкотив цю зміну в наступній версії). Це не те, що я вважав би інтуїтивною поведінкою, але якщо трохи розтягнути свою уяву, легко зрозуміти, як незначний варіант цієї ситуації може стати зупинкою для компілятора. Через це автори специфікацій зробили це "Невизначеною поведінкою" і заявили, що компілятор може робити абсолютно все, що завгодно.

Окрім теоретичних відповідей, практичним спостереженням було б те, що протягом тривалого часу компілятори застосовували різні перетворення на петлях, щоб зменшити обсяг роботи, виконаної в них. Наприклад, враховуючи:

for (int i=0; i<n; i++)
  foo[i] = i*scale;

компілятор може перетворити це на:

int temp = 0;
for (int i=0; i<n; i++)
{
  foo[i] = temp;
  temp+=scale;
}

Таким чином зберігається множення з кожною ітерацією циклу. Додаткова форма оптимізації, яку компілятори адаптували з різним ступенем агресивності, перетворила б це на:

if (n > 0)
{
  int temp1 = n*scale;
  int *temp2 = foo;
  do
  {
    temp1 -= scale;
    *temp2++ = temp1;
  } while(temp1);
}

Навіть на машинах із тихим обтіканням при переповненні це могло б вийти з ладу, якщо було якесь число менше n, яке при множенні на масштаб дало б 0. Це також могло б перетворитися на нескінченний цикл, якщо масштаб читався з пам'яті більше одного разу і щось неочікувано змінив своє значення (у будь-якому випадку, коли "масштаб" може змінити середину циклу без виклику UB, компілятору не буде дозволено виконувати оптимізацію).

Хоча більшість таких оптимізацій не матиме жодних проблем у випадках, коли два короткі типи без знака перемножуються, отримуючи значення, яке знаходиться між INT_MAX + 1 та UINT_MAX, gcc має деякі випадки, коли таке множення всередині циклу може призвести до раннього виходу циклу . Я не помічав такої поведінки, що випливає з інструкцій порівняння у згенерованому коді, але це спостерігається у випадках, коли компілятор використовує переповнення, щоб зробити висновок, що цикл може виконуватися щонайбільше 4 або менше разів; він не за замовчуванням генерує попередження у випадках, коли одні входи спричиняють UB, а інші - ні, навіть якщо його висновки спричиняють ігнорування верхньої межі циклу.

Невизначена поведінка, за визначенням, є сірою зоною. Ви просто не можете передбачити, що він буде чи ні, - ось що означає «невизначена поведінка» .

З незапам'ятних часів програмісти завжди намагалися врятувати залишки визначеності із невизначеної ситуації. У них є якийсь - то код , який вони дійсно хочете використовувати, але виявляється невизначеним, тому вони намагаються стверджувати: «Я знаю , що не визначене, але , звичайно , це не буде, в гіршому випадку, роблять це або це, він ніколи не робити , що . " І іноді ці аргументи є більш-менш правильними - але часто вони помиляються. І оскільки компілятори стають розумнішими та розумнішими (або, дехто може сказати, підступнішими та підступнішими), межі питання постійно змінюються.

Отже, якщо ви хочете написати код, який гарантовано буде працювати і який буде працювати довгий час, є лише один вибір: уникайте невизначеної поведінки будь-якою ціною. По-справжньому, якщо ти балуєшся цим, воно повернеться до тебе.

Одне, що ваш приклад не враховує, це оптимізація. aвстановлюється в циклі, але ніколи не використовується, і оптимізатор міг би це вирішити. Таким чином, правомірно для оптимізатора aповністю відкинути , і в такому випадку вся невизначена поведінка зникає, як жертва буджума.

Однак, звичайно, це саме не визначено, оскільки оптимізація невизначена. :)

Оскільки це питання є подвійними мітками C і C ++, я спробую розглянути обидва. C і C ++ тут ​​застосовують різні підходи.

У C реалізація повинна бути в змозі довести, що буде викликана невизначена поведінка, щоб ставитися до всієї програми так, ніби вона має невизначену поведінку. У прикладі OP здається тривіальним для компілятора довести це, і тому це як би вся програма була невизначена.

Це ми можемо побачити із звіту про дефекти 109, який на суть запитує:

Якщо, однак, стандарт C визнає окреме існування "невизначених значень" (чиє просто створення не передбачає повністю "невизначеної поведінки"), то особа, яка проводить тестування компілятора, може написати такий тест, наприклад, наступний, і він / вона також може очікувати (або, можливо, вимагати), щоб відповідна реалізація, як мінімум, компілювала цей код (і, можливо, також дозволяла йому виконуватися) без "збою".

int array1[5];
int array2[5];
int *p1 = &array1[0];
int *p2 = &array2[0];

int foo()
{
int i;
i = (p1 > p2); /* Must this be "successfully translated"? */
1/0; /* Must this be "successfully translated"? */
return 0;
}

Тож питання в підсумку таке: Чи повинен вищевказаний код бути "успішно перекладеним" (що б це не означало)? (Див. Виноску, додану до підпункту 5.1.1.3.)

і відповідь була така:

Стандарт C використовує термін "невизначена вартість", а не "невизначена вартість". Використання невизначеного значення об'єкта призводить до невизначеної поведінки. У виносці до підпункту 5.1.1.3 зазначається, що реалізація може виробляти будь-яку кількість діагностик, якщо діюча програма все ще правильно перекладена. Якщо вираз, евакуація якого призведе до невизначеної поведінки, з'являється в контексті, де потрібен постійний вираз, програма, що містить, не відповідає строго. Крім того, якщо кожне можливе виконання даної програми призведе до невизначеної поведінки, дана програма не відповідає строго. Відповідна реалізація не повинна не перекладати строго відповідну програму просто тому, що якесь можливе виконання цієї програми призведе до невизначеної поведінки. Оскільки foo ніколи не може бути викликаний, наведений приклад повинен бути успішно перекладений відповідною реалізацією.

У C ++ підхід виглядає більш спокійним і передбачає, що програма має невизначену поведінку, незалежно від того, може реалізація статично це довести чи ні.

У нас є [intro.abstrac] p5, який говорить:

Відповідна реалізація, що виконує добре сформовану програму, повинна виробляти таку ж спостережувану поведінку, як одне з можливих виконання відповідного екземпляра абстрактної машини з тією ж програмою та однаковим входом. Однак, якщо будь-яке таке виконання містить невизначену операцію, цей документ не встановлює вимоги до реалізації, що виконує цю програму з цим входом (навіть щодо операцій, що передують першій невизначеній операції).

Основна відповідь - неправильне (але поширене) помилкове уявлення:

Невизначена поведінка є час виконання нерухомості *. Це НЕ МОЖЕ "подорожувати у часі"!

Деякі операції визначені (за стандартом), що мають побічні ефекти і не можуть бути оптимізовані. Операції, що виконують введення-виведення або доступvolatile цієї категорії належать змінні .

Однак є застереження: UB може бути будь-якою поведінкою, включаючи поведінку, яка скасовує попередні операції. У деяких випадках це може мати подібні наслідки для оптимізації попереднього коду.

Насправді це узгоджується з цитатою у верхній відповіді (наголос мій):

Відповідна реалізація, що виконує добре сформовану програму, повинна виробляти таку ж спостережувану поведінку, як одне з можливих виконання відповідного екземпляра абстрактної машини з тією ж програмою та однаковим входом.
Однак, якщо будь-яке таке виконання містить невизначену операцію, цей Міжнародний стандарт не встановлює вимог до реалізації, що виконує цю програму з цим входом (навіть щодо операцій, що передують першій невизначеній операції).

Так, ця цитата робить говорить «навіть не стосовно операцій , що передують першому невизначеною операції» , але зверніть увагу , що це саме про те , що код в даний час виконується , а не просто компіляції.
Зрештою, невизначена поведінка, якої насправді не досягнуто, нічого не робить, і для того, щоб рядок, що містить UB, був фактично досягнутий, код, що передує йому, повинен виконатись першим!

Так що так, після виконання UB будь-які ефекти попередніх операцій стають невизначеними. Але поки цього не станеться, виконання програми є чітко визначеним.

Однак зауважте, що всі виконання програми, що призводять до цього, можуть бути оптимізовані до еквівалентних програм, включаючи будь-які, які виконують попередні операції, але потім скасовують їх ефекти. Отже, попередній код може бути оптимізований, коли це буде еквівалентно скасуванню їхніх ефектів ; інакше не може. Див. Приклад нижче.

* Примітка: Це не суперечить UB, що виникає під час компіляції . Якщо компілятор дійсно може довести , що UB код буде завжди виконуватися для всіх входів, то UB може поширюватися на час компіляції. Однак для цього потрібно знати, що весь попередній код врешті-решт повертається , що є суворою вимогою. Знову ж, див. Нижче приклад / пояснення.

Щоб зробити це конкретним, зверніть увагу, що наступний код повинен друкуватись fooі чекати вашого введення, незалежно від будь-якої невизначеної поведінки, що слідує за ним:

printf("foo");
getchar();
*(char*)1 = 1;

Однак також зауважте, що немає жодної гарантії, що fooзалишиться на екрані після виникнення UB, або що введений вами символ більше не буде у вхідному буфері; обидві ці операції можна "скасувати", що має подібний ефект до UB "подорож у часі".

Якби getchar()рядка там не було, було б законно оптимізувати рядки тоді і тільки тоді , коли це було б неможливо відрізнити від виводу, fooа потім " відмовитись " від цього.

Чи не можна буде розрізнити ці два, цілком залежатиме від реалізації (тобто від вашого компілятора та стандартної бібліотеки). Наприклад, чи можна printf заблокувати ваш потік тут, очікуючи, поки інша програма прочитає вихідні дані? Або повернеться негайно?

• Якщо вона може заблокувати тут, тоді інша програма може відмовитись прочитати повний результат, і вона може ніколи не повернутися, і, отже, UB може ніколи не відбутися.

• Якщо він може негайно повернутися сюди, тоді ми знаємо, що він повинен повернутися, і тому його оптимізацію абсолютно неможливо відрізнити від його виконання, а потім скасування його наслідків.

Звичайно, оскільки компілятор знає, яка поведінка допустима для його конкретної версії printf, він може відповідно оптимізувати і, отже, printfможе бути оптимізований в деяких випадках, а не в інших. Але, знову ж таки, виправдання полягає в тому, що це неможливо відрізнити від UB, який не робив попередніх операцій, а не в тому, що попередній код "отруєний" через UB.