(Dlaczego) używa niezdefiniowanej niezainicjowanej zmiennej?

Jeżeli mam:

unsigned int x;
x -= x;

jasne jest, że po tym wyrażeniu x powinno być zero, ale gdziekolwiek spojrzę, mówią, że zachowanie tego kodu jest nieokreślone, a nie tylko wartość x(aż do odejmowania).

Dwa pytania:

• Czy zachowanie tego kodu jest rzeczywiście nieokreślone?
  (Np. Czy kod może ulec awarii [lub gorzej] w zgodnym systemie?)

• Jeśli tak, dlaczego C mówi, że zachowanie jest nieokreślone, skoro jest całkowicie jasne, że xpowinno to wynosić zero?

  tj. jaka jest korzyść wynikająca z braku zdefiniowania tutaj zachowania?

Oczywiście kompilator mógłby po prostu użyć dowolnej wartości śmieciowej, którą uznałby za „przydatną” wewnątrz zmiennej i działałby zgodnie z przeznaczeniem… co jest złego w tym podejściu?

Tak, to zachowanie jest nieokreślone, ale z innych powodów niż większość ludzi jest świadoma.

Po pierwsze, użycie wartości zjednostkowanej nie jest samo w sobie niezdefiniowanym zachowaniem, ale wartość jest po prostu nieokreślona. Dostęp do tego jest wtedy UB, jeśli wartość jest reprezentacją pułapki dla typu. Typy bez znaku rzadko mają reprezentacje pułapek, więc po tej stronie będziesz stosunkowo bezpieczny.

To, co sprawia, że ​​zachowanie jest niezdefiniowane, to dodatkowa właściwość twojej zmiennej, a mianowicie to, że „mogła być zadeklarowana z register”, czyli jej adres nigdy nie jest brany. Takie zmienne są traktowane specjalnie, ponieważ istnieją architektury, które mają rzeczywiste rejestry procesora, które mają rodzaj dodatkowego stanu, który jest „niezainicjowany” i który nie odpowiada wartości w domenie typu.

Edycja: Odpowiednia fraza normy to 6.3.2.1p2:

Jeśli lwartość wyznacza obiekt o automatycznym czasie przechowywania, który mógłby zostać zadeklarowany w klasie pamięci rejestru (nigdy nie miał odebranego adresu), a ten obiekt jest niezainicjalizowany (nie zadeklarowany za pomocą inicjatora i żadne przypisanie do niego nie zostało wykonane przed użyciem ), zachowanie jest nieokreślone.

Aby było jaśniej, poniższy kod jest legalny w każdych okolicznościach:

unsigned char a, b;
memcpy(&a, &b, 1);
a -= a;

• Tutaj pobierane są adresy ai b, więc ich wartość jest po prostu nieokreślona.
• Ponieważ unsigned charnigdy nie ma reprezentacji pułapki, że nieokreślona wartość jest po prostu nieokreślona, ​​każda wartość unsigned charmoże się zdarzyć.
• Na końcu a musi mieć wartość 0.

Edit2: a i bmają nieokreślone wartości:

3.19.3 wartość nieokreślona
ważna wartość odpowiedniego typu, jeśli niniejsza norma międzynarodowa nie nakłada żadnych wymagań dotyczących wyboru wartości w jakimkolwiek przypadku

Standard C daje kompilatorom dużą swobodę w przeprowadzaniu optymalizacji. Konsekwencje tych optymalizacji mogą być zaskakujące, jeśli przyjmie się naiwny model programów, w których niezainicjowana pamięć jest ustawiona na jakiś losowy wzorzec bitowy, a wszystkie operacje są wykonywane w kolejności, w jakiej zostały zapisane.

Uwaga: poniższe przykłady są poprawne tylko dlatego, xże jego adres nigdy nie został zajęty, więc jest „podobny do rejestru”. Byłyby również ważne, gdyby typ xmiał reprezentacje pułapki; rzadko ma to miejsce w przypadku typów bez znaku (wymaga to „marnowania” co najmniej jednego bitu pamięci i musi być udokumentowane) i niemożliwe w przypadku unsigned char. Gdyby xmiał typ ze znakiem, to implementacja mogłaby zdefiniować wzór bitowy, który nie jest liczbą między - (2 ^n-1 -1) a 2 ^n-1 -1 jako reprezentację pułapki. Zobacz odpowiedź Jensa Gustedta .

Kompilatory próbują przypisać rejestry do zmiennych, ponieważ rejestry są szybsze niż pamięć. Ponieważ program może wykorzystywać więcej zmiennych niż procesor posiada rejestry, kompilatory dokonują alokacji rejestrów, co prowadzi do różnych zmiennych wykorzystujących ten sam rejestr w różnym czasie. Rozważ fragment programu

unsigned x, y, z;   /* 0 */
y = 0;              /* 1 */
z = 4;              /* 2 */
x = - x;            /* 3 */
y = y + z;          /* 4 */
x = y + 1;          /* 5 */

Kiedy wiersz 3 jest oceniany, xnie jest jeszcze zainicjowany, dlatego (uzasadnia kompilator) wiersz 3 musi być jakimś przypadkiem, który nie może się zdarzyć z powodu innych warunków, których kompilator nie był wystarczająco inteligentny, aby dowiedzieć się. Ponieważ znie jest używany po linii 4 i xnie jest używany przed linią 5, ten sam rejestr może być używany dla obu zmiennych. Tak więc ten mały program jest skompilowany do następujących operacji na rejestrach:

r1 = 0;
r0 = 4;
r0 = - r0;
r1 += r0;
r0 = r1;

Końcowa wartość xto końcowa wartość r0, a końcowa wartość yto końcowa wartość r1. Te wartości to x = -3 i y = -4, a nie 5 i 4, jak by się stało, gdyby xzostał poprawnie zainicjowany.

Aby uzyskać bardziej rozbudowany przykład, rozważ następujący fragment kodu:

unsigned i, x;
for (i = 0; i < 10; i++) {
    x = (condition() ? some_value() : -x);
}

Załóżmy, że kompilator wykryje, że conditionnie ma to żadnego efektu ubocznego. Ponieważ conditionnie modyfikuje x, kompilator wie, że pierwszy przebieg pętli nie może uzyskać dostępu, xponieważ nie został jeszcze zainicjowany. Dlatego pierwsze wykonanie treści pętli jest równoważne x = some_value(), nie ma potrzeby testowania warunku. Kompilator może skompilować ten kod tak, jakbyś to napisał

unsigned i, x;
i = 0; /* if some_value() uses i */
x = some_value();
for (i = 1; i < 10; i++) {
    x = (condition() ? some_value() : -x);
}

Sposób, w jaki można to modelować w kompilatorze, polega na rozważeniu, że każda wartość zależna od xma jakąkolwiek wartość jest wygodna, o ile nie xjest zainicjowana. Ponieważ zachowanie, gdy niezainicjowana zmienna jest niezdefiniowana, a nie zmienna ma jedynie nieokreśloną wartość, kompilator nie musi śledzić żadnych specjalnych matematycznych relacji między wartościami, które są wygodne. Dlatego kompilator może przeanalizować powyższy kod w następujący sposób:

• podczas pierwszej iteracji pętli nie xjest inicjowany do czasu -xoceny.
• -x ma niezdefiniowane zachowanie, więc jego wartość jest taka, jaka jest-wygodna.
• Obowiązuje reguła optymalizacji , więc ten kod można uprościć do .condition ? value : valuecondition; value

W konfrontacji z kodem w twoim pytaniu, ten sam kompilator analizuje, że kiedy x = - xjest oceniany, wartość -xjest cokolwiek-jest-wygodne. Dzięki temu można zoptymalizować przypisanie.

Nie szukałem przykładu kompilatora, który zachowuje się tak, jak opisano powyżej, ale jest to rodzaj optymalizacji, który dobre kompilatory próbują wykonać. Nie zdziwiłbym się, gdyby takiego spotkałem. Oto mniej prawdopodobny przykład kompilatora, z którym program ulega awarii. (Może to nie być takie nieprawdopodobne, jeśli kompilujesz swój program w jakimś zaawansowanym trybie debugowania).

Ten hipotetyczny kompilator mapuje każdą zmienną na innej stronie pamięci i ustawia atrybuty strony w taki sposób, że odczyt z niezainicjowanej zmiennej powoduje pułapkę procesora, która wywołuje debugger. Każde przypisanie do zmiennej najpierw upewnia się, że jej strona pamięci jest odwzorowana normalnie. Ten kompilator nie próbuje wykonywać żadnej zaawansowanej optymalizacji - działa w trybie debugowania, mającym na celu łatwe lokalizowanie błędów, takich jak niezainicjowane zmienne. Gdy x = - xjest oceniany, prawa strona powoduje pułapkę i uruchamia debuger.

Tak, program może ulec awarii. Mogą na przykład istnieć reprezentacje pułapek (określone wzorce bitów, których nie można obsłużyć), które mogą spowodować przerwanie procesora, które nieobsłużone może spowodować awarię programu.

(6.2.6.1 na późnym szkicu C11 mówi) Niektóre reprezentacje obiektów nie muszą przedstawiać wartości typu obiektu. Jeśli przechowywana wartość obiektu ma taką reprezentację i jest odczytywana przez wyrażenie l-wartości, które nie ma typu znakowego, zachowanie jest niezdefiniowane. Jeśli taka reprezentacja jest wytwarzana przez efekt uboczny, który modyfikuje całość lub jakąkolwiek część obiektu za pomocą wyrażenia l-wartości, które nie ma typu znakowego, zachowanie jest niezdefiniowane.50) Taka reprezentacja nazywa się reprezentacją pułapki.

(To wyjaśnienie ma zastosowanie tylko na platformach, na których unsigned intmożna przedstawić pułapki, co jest rzadkością w rzeczywistych systemach; szczegółowe informacje i odniesienia do alternatywnych i być może bardziej powszechnych przyczyn, które prowadzą do aktualnego brzmienia normy, można znaleźć w komentarzach).

(Ta odpowiedź dotyczy C 1999. Dla C 2011, patrz odpowiedź Jensa Gustedta.)

Standard C nie mówi, że użycie wartości obiektu automatycznego czasu trwania przechowywania, który nie jest zainicjowany, jest niezdefiniowanym zachowaniem. Norma C 1999 mówi, w 6.7.8 10, „Jeśli obiekt, który ma automatyczny czas przechowywania, nie jest jawnie zainicjowany, jego wartość jest nieokreślona”. (W tym akapicie opisano, w jaki sposób inicjowane są obiekty statyczne, więc jedynymi niezainicjowanymi obiektami, o które się martwimy, są obiekty automatyczne).

3.17.2 definiuje „nieokreśloną wartość” jako „nieokreśloną wartość lub reprezentację pułapki”. 3.17.3 definiuje „nieokreśloną wartość” jako „ważną wartość odpowiedniego typu, jeśli niniejsza Norma Międzynarodowa nie nakłada żadnych wymagań dotyczących wyboru wartości w jakimkolwiek przypadku”.

Tak więc, jeśli niezainicjowany unsigned int xma nieokreśloną wartość, to x -= xmusi dać zero. Pozostaje pytanie, czy może to być reprezentacja pułapki. Dostęp do wartości pułapki powoduje niezdefiniowane zachowanie, zgodnie z 6.2.6.1 5.

Niektóre typy obiektów mogą mieć reprezentacje pułapek, takie jak sygnalizacyjne NaN liczb zmiennoprzecinkowych. Ale liczby całkowite bez znaku są wyjątkowe. Zgodnie z 6.2.6.2, każdy z N bitów wartości liczby int bez znaku reprezentuje potęgę 2, a każda kombinacja bitów wartości reprezentuje jedną z wartości od 0 do 2 ^N -1. Tak więc liczby całkowite bez znaku mogą mieć reprezentacje pułapek tylko z powodu pewnych wartości w ich bitach wypełniających (takich jak bit parzystości).

Jeśli na platformie docelowej bez znaku int nie ma bitów wypełnienia, to niezainicjowany int bez znaku nie może mieć reprezentacji pułapki, a użycie jego wartości nie może spowodować niezdefiniowanego zachowania.

Tak, to nie jest zdefiniowane. Kod może ulec awarii. C mówi, że zachowanie jest nieokreślone, ponieważ nie ma konkretnego powodu, aby robić wyjątek od ogólnej reguły. Zaletą jest ta sama zaleta, co wszystkie inne przypadki niezdefiniowanego zachowania - kompilator nie musi wyprowadzać specjalnego kodu, aby to zadziałało.

Oczywiście kompilator mógłby po prostu użyć dowolnej wartości śmieciowej, którą uznałby za „przydatną” wewnątrz zmiennej i działałby zgodnie z przeznaczeniem… co jest złego w tym podejściu?

Jak myślisz, dlaczego tak się nie dzieje? Dokładnie takie podejście zostało przyjęte. Kompilator nie jest wymagany, aby działał, ale nie jest wymagany do tego, aby się nie udał.

W przypadku dowolnej zmiennej dowolnego typu, która nie została zainicjowana lub z innych powodów ma nieokreśloną wartość, do kodu odczytującego tę wartość stosuje się następujące zasady:

• W przypadku, gdy zmienna ma automatyczny czas trwania i nie ma zajętego adresu, kod zawsze wywołuje niezdefiniowane zachowanie [1].
• W przeciwnym razie, jeśli system obsługuje reprezentacje pułapek dla danego typu zmiennej, kod zawsze wywoła niezdefiniowane zachowanie [2].

• W przeciwnym razie, jeśli nie ma reprezentacji pułapek, zmienna przyjmuje nieokreśloną wartość. Nie ma gwarancji, że ta nieokreślona wartość jest spójna przy każdym odczycie zmiennej. Jednak gwarantuje się, że nie będzie reprezentacją pułapki, a zatem gwarantuje się, że nie wywoła niezdefiniowanego zachowania [3].

  Wartość może być następnie bezpiecznie używana bez powodowania awarii programu, chociaż taki kod nie jest przenośny do systemów z reprezentacjami pułapek.

[1]: C11 6.3.2.1:

Jeśli lwartość wyznacza obiekt o automatycznym czasie przechowywania, który mógłby zostać zadeklarowany w klasie pamięci rejestru (nigdy nie miał odebranego adresu), a ten obiekt jest niezainicjalizowany (nie zadeklarowany za pomocą inicjatora i żadne przypisanie do niego nie zostało wykonane przed użyciem ), zachowanie jest nieokreślone.

[2]: C11 6.2.6.1:

Niektóre reprezentacje obiektów nie muszą przedstawiać wartości typu obiektu. Jeśli przechowywana wartość obiektu ma taką reprezentację i jest odczytywana przez wyrażenie l-wartości, które nie ma typu znakowego, zachowanie jest niezdefiniowane. Jeśli taka reprezentacja jest wytwarzana przez efekt uboczny, który modyfikuje całość lub jakąkolwiek część obiektu za pomocą wyrażenia l-wartości, które nie ma typu znakowego, zachowanie jest niezdefiniowane.50) Taka reprezentacja nazywa się reprezentacją pułapki.

[3] C11:

3.19.2
nieokreślona wartość
nieokreślona wartość lub reprezentacja pułapki

3.19.3
wartość nieokreślona
ważna wartość odpowiedniego typu, jeśli niniejsza Norma Międzynarodowa nie nakłada żadnych wymagań, co do której wartość jest wybierana w jakimkolwiek przypadku
UWAGA Nieokreślona wartość nie może być reprezentacją pułapki.

3.19.4
reprezentacja pułapki reprezentacja
obiektu, która nie musi przedstawiać wartości typu obiektu

Podczas gdy wiele odpowiedzi koncentruje się na procesorach, które pułapki na dostęp do niezainicjowanych rejestrów, dziwaczne zachowania mogą pojawić się nawet na platformach, które nie mają takich pułapek, przy użyciu kompilatorów, które nie podejmują żadnego szczególnego wysiłku w celu wykorzystania UB. Rozważ kod:

volatile uint32_t a,b;
uin16_t moo(uint32_t x, uint16_t y, uint32_t z)
{
  uint16_t temp;
  if (a)
    temp = y;
  else if (b)
    temp = z;
  return temp;  
}

kompilator dla platformy takiej jak ARM, w której wszystkie instrukcje inne niż ładowanie i magazyny działają w 32-bitowych rejestrach, może rozsądnie przetwarzać kod w sposób równoważny z:

volatile uint32_t a,b;
// Note: y is known to be 0..65535
// x, y, and z are received in 32-bit registers r0, r1, r2
uin32_t moo(uint32_t x, uint32_t y, uint32_t z)
{
  // Since x is never used past this point, and since the return value
  // will need to be in r0, a compiler could map temp to r0
  uint32_t temp;
  if (a)
    temp = y;
  else if (b)
    temp = z & 0xFFFF;
  return temp;  
}

Jeśli którykolwiek z nietrwałych odczytów dadzą wartość niezerową, r0 zostanie załadowany wartością z zakresu 0 ... 65535. W przeciwnym razie zwróci wszystko, co trzymał, gdy wywołano funkcję (tj. Wartość przekazaną do x), co może nie być wartością z zakresu 0..65535. W standardzie brakuje terminologii opisującej zachowanie wartości typu uint16_t, ale której wartość jest poza zakresem 0..65535, z wyjątkiem stwierdzenia, że ​​każda akcja, która mogłaby spowodować takie zachowanie, wywołuje UB.