Чи є a ^ a чи aa невизначеною поведінкою, якщо a не ініціалізовано?

Розглянемо цю програму:

#include <stdio.h>

int main(void)
{
    unsigned int a;
    printf("%u %u\n", a^a, a-a);
    return 0;
}

Це невизначена поведінка?

На перший погляд, aце неініціалізована змінна. Це вказує на невизначену поведінку. Але a^aі a-aрівні 0для всіх значень a, принаймні я думаю, що це так. Чи можливо, що існує якийсь спосіб стверджувати, що поведінка чітко визначена?

У C11:

• Це явно не визначено відповідно до 6.3.2.1/2, якщо aніколи не береться його адреса (цитується нижче)
• Це може бути уявлення про пастку (що викликає UB при доступі). 6.2.6.1/5:

Певні представлення об'єктів не обов'язково представляють значення типу об'єкта.

Непідписані ints можуть мати уявлення про пастки (наприклад, якщо він має 15 бітів точності та 1 біт парності, доступ aможе спричинити помилку парності).

6.2.4 / 6 говорить, що початкове значення є невизначеним, а визначення під п. 3.19.2 є або невизначеним значенням, або поданням пастки .

Далі: у C11 6.3.2.1/2, як зазначив Паскаль Куок:

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

Це не має винятку для типів символів, тому цей пункт, здається, замінює попереднє обговорення; доступ xнегайно не визначений, навіть якщо представлення пастки не існує. Цей пункт було додано до C11 для підтримки процесорів Itanium, які насправді мають стан захоплення для реєстрів.

Системи без уявлення про пастки: Але що, якщо ми кинемо &x;так, що заперечення 6.3.2.1/2 більше не застосовуватиметься, і ми знаходимося в системі, яка, як відомо, не має уявлень про пастки? Тоді значення є невизначеним значенням . Визначення невизначеного значення в 3.19.3 є дещо розмитим, проте воно пояснюється в DR 451 , який робить висновок:

• Неініціалізоване значення за описаних умов може змінити його значення.
• Будь-яка операція, виконана з невизначеними значеннями, матиме в результаті невизначене значення.
• Функції бібліотеки виявлятимуть невизначену поведінку при використанні з невизначеними значеннями.
• Ці відповіді підходять для всіх типів, які не мають уявлень про пастки.

Згідно з цією резолюцією, int a; &a; int b = a - a;результат bзалишається невизначеним.

Зверніть увагу, що якщо невизначене значення не передається функції бібліотеки, ми все ще знаходимося у сфері невизначеної поведінки (не невизначеної поведінки). Результати можуть бути дивними, наприклад, if ( j != j ) foo();можна подзвонити Фу, але демони повинні залишатися закріпленими в носовій порожнині.

Так, це невизначена поведінка.

По-перше, будь-яка неініціалізована змінна може мати "зламане" (воно ж "пастка") подання. Навіть одна спроба отримати доступ до цього подання викликає невизначену поведінку. Більше того, навіть об'єкти не захоплюючих типів (на зразок unsigned char) все ще можуть отримувати спеціальні стани, що залежать від платформи (наприклад, NaT - Not-A-Thing - на Itanium), що може виглядати як прояв їх "невизначеного значення".

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

Якщо об’єкт має автоматичну тривалість зберігання і його адреса не береться, спроба його прочитати дасть невизначену поведінку. Беручи адресу такого об'єкта та використовуючи покажчики типу "unsigned char" для зчитування його байтів, Стандарт гарантує отримання значення типу "unsigned char", але не всі компілятори дотримуються цього стандарту. . ARM GCC 5.1, наприклад, коли дано:

  #include <stdint.h>
  #include <string.h>
  struct q { uint16_t x,y; };
  volatile uint16_t zz;
  int32_t foo(uint32_t x, uint32_t y)
  {
    struct q temp1,temp2;
    temp1.x = 3;
    if (y & 1)
      temp1.y = zz;
    memmove(&temp2,&temp1,sizeof temp1);
    return temp2.y;
  }

згенерує код, який поверне x, якщо y дорівнює нулю, навіть якщо x знаходиться поза діапазоном 0-65535. Стандарт чітко пояснює, що беззнакові читання символів невизначеного значення гарантовано дають значення в діапазоні unsigned char, а поведінка параметра memmoveвизначається як еквівалентна послідовності читання та запису символів. Таким чином, temp2 повинен мати значення, яке могло б зберігатися в ньому через послідовність записів символів, але gcc вирішує замінити memmove присвоєнням та ігнорувати той факт, що код прийняв адресу temp1 і temp2.

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