Czy gałęzie z niezdefiniowanym zachowaniem można uznać za nieosiągalne i zoptymalizowane jako martwy kod?

Rozważ następujące stwierdzenie:

*((char*)NULL) = 0; //undefined behavior

Wyraźnie wywołuje niezdefiniowane zachowanie. Czy istnienie takiej instrukcji w danym programie oznacza, że ​​cały program jest niezdefiniowany, czy też zachowanie staje się niezdefiniowane dopiero, gdy przepływ sterowania osiągnie tę instrukcję?

Czy następujący program byłby dobrze zdefiniowany, gdyby użytkownik nigdy nie wprowadził numeru 3?

while (true) {
 int num = ReadNumberFromConsole();
 if (num == 3)
  *((char*)NULL) = 0; //undefined behavior
}

A może jest to całkowicie niezdefiniowane zachowanie bez względu na to, co wprowadzi użytkownik?

Czy kompilator może również założyć, że niezdefiniowane zachowanie nigdy nie zostanie wykonane w czasie wykonywania? To pozwoliłoby na cofanie się w czasie:

int num = ReadNumberFromConsole();

if (num == 3) {
 PrintToConsole(num);
 *((char*)NULL) = 0; //undefined behavior
}

W tym przypadku kompilator może stwierdzić, że w przypadku, num == 3gdy zawsze będziemy wywoływać niezdefiniowane zachowanie. Dlatego ten przypadek musi być niemożliwy, a numer nie musi być drukowany. Cała ifinstrukcja mogłaby zostać zoptymalizowana. Czy tego rodzaju rozumowanie wstecz jest dozwolone zgodnie ze standardem?

Czy istnienie takiej instrukcji w danym programie oznacza, że ​​cały program jest niezdefiniowany, czy też zachowanie staje się niezdefiniowane dopiero, gdy przepływ sterowania osiągnie tę instrukcję?

Ani. Pierwszy warunek jest za silny, a drugi za słaby.

Dostęp do obiektów jest czasami sekwencjonowany, ale standard opisuje zachowanie programu poza czasem. Danvil już cytował:

jeżeli jakiekolwiek takie wykonanie zawiera nieokreśloną operację, niniejsza Norma Międzynarodowa nie nakłada żadnych wymagań na implementację wykonującą ten program z tymi danymi wejściowymi (nawet w odniesieniu do operacji poprzedzających pierwszą niezdefiniowaną operację)

Można to zinterpretować:

Jeśli wykonanie programu daje niezdefiniowane zachowanie, to cały program ma niezdefiniowane zachowanie.

Tak więc nieosiągalna instrukcja z UB nie daje programowi UB. Osiągalna instrukcja, która (ze względu na wartości wejść) nigdy nie jest osiągnięta, nie daje programowi UB. Dlatego twój pierwszy stan jest zbyt silny.

Teraz kompilator nie może ogólnie powiedzieć, co ma UB. Tak więc, aby umożliwić optymalizatorowi zmianę kolejności instrukcji z potencjalnym UB, który byłby możliwy do ponownego uporządkowania w przypadku zdefiniowania ich zachowania, konieczne jest zezwolenie UB na „cofnięcie się w czasie” i popełnienie błędu przed poprzednim punktem sekwencji (lub w C ++ 11 terminologia, aby UB wpływał na rzeczy, które są sekwencjonowane przed rzeczą UB). Dlatego twój drugi stan jest zbyt słaby.

Głównym tego przykładem jest sytuacja, w której optymalizator opiera się na ścisłym aliasingu. Cały sens ścisłych reguł aliasingu polega na umożliwieniu kompilatorowi zmiany kolejności operacji, które nie mogłyby zostać poprawnie uporządkowane, gdyby było możliwe, że odnośne wskaźniki aliasują tę samą pamięć. Więc jeśli użyjesz nielegalnych wskaźników aliasingu, a UB wystąpi, może to łatwo wpłynąć na instrukcję „przed” instrukcją UB. Jeśli chodzi o maszynę abstrakcyjną, instrukcja UB nie została jeszcze wykonana. Jeśli chodzi o rzeczywisty kod wynikowy, został on częściowo lub w całości wykonany. Ale norma nie próbuje wchodzić w szczegóły dotyczące tego, co oznacza dla optymalizatora ponowne uporządkowanie instrukcji ani jakie są tego konsekwencje dla UB. Po prostu daje licencję wdrożeniową na błąd, gdy tylko zechce.

Możesz myśleć o tym jako o „UB ma maszynę czasu”.

W szczególności, aby odpowiedzieć na twoje przykłady:

• Zachowanie jest niezdefiniowane tylko wtedy, gdy odczytuje się 3.
• Kompilatory mogą i eliminują kod jako martwy, jeśli podstawowy blok zawiera operację, która z pewnością jest niezdefiniowana. Są dozwolone (i przypuszczam, że tak) w przypadkach, które nie są podstawowym blokiem, ale wszystkie gałęzie prowadzą do UB. Ten przykład nie jest kandydatem, chyba że w PrintToConsole(3)jakiś sposób wiadomo, że wróci. Może zgłosić wyjątek lub cokolwiek.

Podobnym przykładem do twojego drugiego jest opcja gcc -fdelete-null-pointer-checks, która może przyjmować taki kod (nie sprawdzałem tego konkretnego przykładu, uważam, że ilustruje on ogólną ideę):

void foo(int *p) {
    if (p) *p = 3;
    std::cout << *p << '\n';
}

i zmień go na:

*p = 3;
std::cout << "3\n";

Czemu? Ponieważ jeśli pjest null, to i tak kod ma UB, więc kompilator może założyć, że nie jest null i odpowiednio zoptymalizować. Jądro Linuksa potknęło się o to ( https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1897 ) głównie dlatego, że działa w trybie, w którym wyłuskiwanie wskaźnika zerowego nie powinno być UB, oczekuje się, że spowoduje zdefiniowany wyjątek sprzętowy, który jądro może obsłużyć. Gdy optymalizacja jest włączona, gcc wymaga użycia -fno-delete-null-pointer-checksw celu zapewnienia ponadstandardowej gwarancji.

PS Praktyczna odpowiedź na pytanie „kiedy pojawia się niezdefiniowane zachowanie?” to „10 minut przed planowanym wyjazdem na cały dzień”.

Norma wskazuje na 1,9 / 4

[Uwaga: Niniejsza Norma Międzynarodowa nie nakłada żadnych wymagań dotyczących zachowania programów, które zawierają nieokreślone zachowanie. - notatka końcowa]

Ciekawostką jest prawdopodobnie to, co oznacza „zawierać”. Nieco później przy 1,9 / 5 mówi:

Jednakże, jeśli jakiekolwiek takie wykonanie zawiera nieokreśloną operację, niniejsza Norma Międzynarodowa nie nakłada żadnych wymagań na implementację wykonującą ten program z tym wejściem (nawet w odniesieniu do operacji poprzedzających pierwszą niezdefiniowaną operację)

Tutaj konkretnie wspomina się o „wykonaniu… z tym wejściem”. Zinterpretowałbym to jako niezdefiniowane zachowanie w jednej możliwej gałęzi, która nie jest teraz wykonywana, nie wpływa na bieżącą gałąź wykonania.

Inną kwestią są jednak założenia oparte na niezdefiniowanym zachowaniu podczas generowania kodu. Zobacz odpowiedź Steve'a Jessopa, aby uzyskać więcej informacji na ten temat.

Pouczającym przykładem jest

int foo(int x)
{
    int a;
    if (x)
        return a;
    return 0;
}

Zarówno obecne GCC, jak i bieżące Clang zoptymalizują to (na x86) do

xorl %eax,%eax
ret

ponieważ wywnioskowali, że xjest to zawsze zero z UB w if (x)ścieżce sterowania. GCC nawet nie daje ostrzeżenia o użyciu niezainicjowanej wartości! (ponieważ przebieg, który stosuje powyższą logikę, jest uruchamiany przed przebiegiem, który generuje ostrzeżenia o niezainicjowanej wartości)

Obecna robocza wersja robocza C ++ mówi, że w 1.9.4

Niniejsza Norma Międzynarodowa nie nakłada żadnych wymagań na zachowanie programów, które wykazują nieokreślone zachowanie.

Na tej podstawie powiedziałbym, że program zawierający niezdefiniowane zachowanie na dowolnej ścieżce wykonywania może zrobić wszystko w każdym momencie swojego wykonania.

Istnieją dwa naprawdę dobre artykuły na temat niezdefiniowanego zachowania i tego, co zwykle robią kompilatory:

• Przewodnik po niezdefiniowanym zachowaniu w C i C ++
• Co każdy programista języka C powinien wiedzieć o niezdefiniowanym zachowaniu

Słowo „zachowanie” oznacza, że ​​coś się dzieje . Stan, który nigdy nie jest wykonywany, nie jest „zachowaniem”.

Ilustracja:

*ptr = 0;

Czy to niezdefiniowane zachowanie? Załóżmy, że jesteśmy na 100% pewni ptr == nullptrprzynajmniej raz podczas wykonywania programu. Odpowiedź powinna brzmieć tak.

A co z tym?

 if (ptr) *ptr = 0;

Czy to jest nieokreślone? (Pamiętasz ptr == nullptrprzynajmniej raz?) Mam nadzieję, że nie, bo inaczej nie będziesz w stanie napisać żadnego użytecznego programu.

Udzielając tej odpowiedzi, żaden srandardese nie ucierpiał.

Niezdefiniowane zachowanie pojawia się, gdy program spowoduje niezdefiniowane zachowanie bez względu na to, co stanie się później. Jednak podałeś następujący przykład.

int num = ReadNumberFromConsole();

if (num == 3) {
 PrintToConsole(num);
 *((char*)NULL) = 0; //undefined behavior
}

Dopóki kompilator nie zna definicji PrintToConsole, nie może usunąć if (num == 3)warunku. Załóżmy, że masz LongAndCamelCaseStdio.hnagłówek systemowy z następującą deklaracją PrintToConsole.

void PrintToConsole(int);

Nic zbyt pomocnego, w porządku. Teraz zobaczmy, jak zły (lub może nie tak zły, niezdefiniowany sposób mógł być gorszy) sprzedawca, sprawdzając rzeczywistą definicję tej funkcji.

int printf(const char *, ...);
void exit(int);

void PrintToConsole(int num) {
    printf("%d\n", num);
    exit(0);
}

W rzeczywistości kompilator musi założyć, że dowolna funkcja, której kompilator nie wie, co robi, może zakończyć działanie lub zgłosić wyjątek (w przypadku C ++). Możesz zauważyć, że *((char*)NULL) = 0;nie zostanie to wykonane, ponieważ wykonanie nie będzie kontynuowane po PrintToConsolewywołaniu.

Nieokreślone zachowanie uderza, gdy PrintToConsolefaktycznie powraca. Kompilator spodziewa się, że tak się nie stanie (ponieważ spowodowałoby to wykonanie przez program niezdefiniowanego zachowania bez względu na wszystko), dlatego wszystko może się zdarzyć.

Zastanówmy się jednak nad czymś innym. Powiedzmy, że robimy sprawdzanie wartości null i używamy zmiennej po sprawdzeniu wartości null.

int putchar(int);

const char *warning;

void lol_null_check(const char *pointer) {
    if (!pointer) {
        warning = "pointer is null";
    }
    putchar(*pointer);
}

W tym przypadku łatwo zauważyć, że lol_null_checkwymaga to wskaźnika innego niż NULL. Przypisanie do globalnej warningzmiennej nieulotnej nie jest czymś, co mogłoby zakończyć działanie programu lub zgłosić wyjątek. pointerJest nieulotna, więc nie może magicznie zmienić jego wartość w środku funkcji (jeśli tak, to niezdefiniowane zachowanie). Wywołanie lol_null_check(NULL)spowoduje niezdefiniowane zachowanie, które może spowodować nieprzypisanie zmiennej (ponieważ w tym momencie znany jest fakt, że program wykonuje niezdefiniowane zachowanie).

Jednak niezdefiniowane zachowanie oznacza, że ​​program może zrobić wszystko. Dlatego nic nie powstrzymuje niezdefiniowanego zachowania przed cofnięciem się w czasie i awarią programu przed wykonaniem pierwszej linii int main(). To niezdefiniowane zachowanie, nie musi mieć sensu. Równie dobrze może się zawiesić po wpisaniu 3, ale niezdefiniowane zachowanie cofnie się w czasie i ulegnie awarii, zanim wpiszesz 3. A kto wie, być może niezdefiniowane zachowanie nadpisze pamięć RAM systemu i spowoduje awarię systemu 2 tygodnie później, gdy niezdefiniowany program nie jest uruchomiony.

Jeśli program dotrze do instrukcji wywołującej niezdefiniowane zachowanie, żadne wymagania nie są nakładane na żadne wyjście / zachowanie programu; nie ma znaczenia, czy miałyby miejsce „przed” czy „po” wywołaniu niezdefiniowanego zachowania.

Twoje rozumowanie dotyczące wszystkich trzech fragmentów kodu jest poprawne. W szczególności kompilator może potraktować każdą instrukcję, która bezwarunkowo wywołuje niezdefiniowane zachowanie, tak jak traktuje GCC __builtin_unreachable(): jako wskazówkę optymalizacyjną, że instrukcja jest nieosiągalna (a tym samym, że wszystkie ścieżki kodu prowadzące do niej bezwarunkowo są również nieosiągalne). Możliwe są oczywiście inne podobne optymalizacje.

Wiele standardów dla wielu rodzajów rzeczy wymaga wiele wysiłku na opisanie rzeczy, których implementacje POWINNY lub NIE POWINNY robić, używając nazewnictwa podobnego do zdefiniowanego w IETF RFC 2119 (choć niekoniecznie cytując definicje w tym dokumencie). W wielu przypadkach opisy rzeczy, które implementacje powinny robić, z wyjątkiem przypadków, w których byłyby bezużyteczne lub niepraktyczne, są ważniejsze niż wymagania, które muszą spełniać wszystkie zgodne implementacje.

Niestety, standardy C i C ++ mają tendencję do unikania opisów rzeczy, które chociaż nie są wymagane w 100%, to jednak nie należy się ich spodziewać po implementacjach wysokiej jakości, które nie dokumentują sprzecznych zachowań. Sugestia, że ​​implementacje powinny coś zrobić, może być postrzegana jako sugerująca, że ​​te, które nie są gorsze, aw przypadkach, w których ogólnie byłoby oczywiste, które zachowania byłyby przydatne lub praktyczne, w porównaniu z niepraktycznymi i bezużytecznymi, w danej implementacji Niewielka dostrzegana potrzeba, aby Norma ingerowała w takie osądy.

Sprytny kompilator mógłby być zgodny ze standardem, eliminując jednocześnie kod, który nie miałby żadnego efektu, z wyjątkiem sytuacji, gdy kod otrzymuje dane wejściowe, które nieuchronnie spowodowałyby niezdefiniowane zachowanie, ale „sprytny” i „głupi” nie są antonimami. Fakt, że autorzy Standardu uznali, że mogą istnieć rodzaje implementacji, w których użyteczne zachowanie w danej sytuacji byłoby bezużyteczne i niepraktyczne, nie oznacza żadnego osądu, czy takie zachowania należy uznać za praktyczne i przydatne dla innych. Gdyby implementacja mogła utrzymać gwarancję behawioralną bez żadnych kosztów poza utratą możliwości przycinania „martwej gałęzi”, prawie każda wartość, jaką kod użytkownika mógłby uzyskać z tej gwarancji, przekroczyłaby koszt jej dostarczenia. Eliminacja martwych gałęzi może być w porządku w przypadkach, w których nieale jeśli w danej sytuacji kod użytkownika mógłby obsłużyć prawie każde możliwe zachowanie inne niż eliminacja martwej gałęzi, każdy wysiłek, jaki kod użytkownika musiałby poświęcić, aby uniknąć UB, prawdopodobnie przekroczyłby wartość uzyskaną z DBE.