Niezdefiniowane zachowanie w C++ (UB): czym jest i jak go unikać

Co naprawdę oznacza "niezdefiniowane zachowanie"

Poprzednia strona pokazuje, jak try/catch obsługuje błędy, które twój program definiuje i celowo rzuca. Niezdefiniowane zachowanie to przeciwieństwo: zbiór operacji, którym standard C++ w ogóle odmawia znaczenia. Nie ma wyjątku do złapania, kodu błędu ani gwarancji awarii. Kompilator może założyć, że UB nigdy nie wystąpi, i zrobić cokolwiek zechce, gdy jednak wystąpi.

Ta swoboda sprawia, że UB jest tak niebezpieczne. Ta sama błędna linia może wypisać "poprawny" wynik na twoim laptopie, zwrócić śmieci na serwerze i zostać całkowicie usunięta przez optymalizator przy -O2. UB to nie "zachowanie, którego nie dokumentujemy", tylko "zachowanie, o którym język niczego nie obiecuje". Twoje zadanie to w ogóle go nie pisać.

int arr[3] = {1, 2, 3};
int x = arr[5];   // niezdefiniowane zachowanie: odczyt poza końcem tablicy

Nie ma tu błędu kompilacji, a przy wielu uruchomieniach program po cichu poda ci przypadkową liczbę całkowitą. Ten pozorny sukces to właśnie pułapka.

Odczyt lub zapis poza zakresem

Najczęstsza postać UB to sięganie do pamięci, która do ciebie nie należy. Wbudowane tablice i std::vector::operator[] nie sprawdzają zakresu: indeks za końcem (albo ujemny) to natychmiastowe UB, niezależnie od tego, czy czytasz, czy zapisujesz.

#include <iostream>
#include <vector>
using namespace std;

int main() {
    vector<int> v = {10, 20, 30};

    // Bezpieczny dostęp:
    for (size_t i = 0; i < v.size(); i++) {
        cout << v[i] << " ";
    }
    cout << "\n";

    // Klasyczny błąd o jeden wyglądałby tak:
    //   for (size_t i = 0; i <= v.size(); i++)  // i == size() jest poza zakresem!
    return 0;
}

Wypatruj <= tam, gdzie miało być <: gdy i == v.size(), sięgasz o jeden element za ostatni, co jest UB. Gdy nie potrzebujesz indeksu, wybieraj pętlę for po zakresie (omówioną wcześniej), bo ona nie wyjdzie poza koniec. Gdy jednak indeksujesz ręcznie i chcesz siatki bezpieczeństwa, v.at(i) rzuca std::out_of_range zamiast po cichu psuć pamięć:

#include <iostream>
#include <vector>
#include <stdexcept>
using namespace std;

int main() {
    vector<int> v = {10, 20, 30};
    try {
        cout << v.at(5) << "\n";   // sprawdzane: rzuca wyjątek zamiast UB
    } catch (const out_of_range& e) {
        cout << "caught: " << e.what() << "\n";
    }
    return 0;
}

Używaj at() podczas polowania na błąd, a w gorących pętlach wróć do [], gdy już wiadomo, że indeksy są poprawne.

Wiszące wskaźniki i użycie po zwolnieniu

Wskaźnik lub referencja, które żyją dłużej niż obiekt, na który wskazują, są wiszące (dangling). Ich użycie to UB: pamięć mogła zostać ponownie użyta, zwolniona albo nigdy nie istnieć. Przed tą pułapką chronią inteligentne wskaźniki (z poprzedniego rozdziału), ale surowe wskaźniki wciąż pozwalają w nią wpaść.

Najostrzejsza wersja to zwracanie adresu zmiennej lokalnej. Zmienna lokalna znika, gdy funkcja się kończy, więc wywołujący zostaje ze wskaźnikiem na nic:

int* makeNumber() {
    int n = 42;
    return &n;   // zwraca adres zmiennej lokalnej: po return już jej nie ma
}
// Dereferencja wyniku to niezdefiniowane zachowanie.

To samo dzieje się po delete albo gdy vector realokuje pamięć i unieważnia iteratory lub wskaźniki do swoich elementów:

int* p = new int(5);
delete p;
cout << *p;   // użycie po zwolnieniu: niezdefiniowane zachowanie

vector<int> v = {1, 2, 3};
int* first = &v[0];
v.push_back(4);   // może realokować: 'first' jest teraz wiszący
cout << *first;   // niezdefiniowane zachowanie

Obrona to rzeczy, które już znasz: utrzymuj obiekty przy życiu tak długo, jak potrzebuje ich jakikolwiek wskaźnik, wybieraj referencje i inteligentne wskaźniki zamiast surowych wskaźników posiadających, a po każdej operacji, która może zmienić rozmiar kontenera, pobieraj wskaźniki i iteratory od nowa.

Niezainicjalizowane zmienne i przepełnienie liczb ze znakiem

Odczyt zmiennej typu wbudowanego, zanim nadasz jej wartość, to UB: nie ma domyślnego 0. Zmienna zawiera takie bity, jakie akurat były w tej pamięci, a optymalizator może założyć, że nigdy nie czytasz jej niezainicjalizowanej.

#include <iostream>
using namespace std;

int main() {
    int x = 0;        // zawsze inicjalizuj
    int sum = 0;      // zwłaszcza akumulatory

    for (int i = 1; i <= 5; i++) {
        sum += i;
    }
    cout << "sum = " << sum << "\n";   // sum = 15
    return 0;
}

Gdyby sum zadeklarowano jako gołe int sum;, każde sum += i najpierw odczytywałoby nieokreśloną wartość. To UB i wyjątkowo trudny do znalezienia błąd, bo często wygląda, jakby wszystko działało. Wyrób sobie nawyk inicjalizacji: int x = 0; albo int x{};.

Kolejny cichy winowajca to przepełnienie liczby całkowitej ze znakiem. Przekroczenie maksimum przez int ze znakiem to UB (typy bez znaku zawijają się przewidywalnie, typy ze znakiem nie):

int big = 2147483647;   // INT_MAX dla 32-bitowego int
int oops = big + 1;     // przepełnienie ze znakiem: niezdefiniowane zachowanie

Nie licz na to, że wartość "zawinie się do liczby ujemnej": kompilator może założyć, że przepełnienie nie wystąpi, i optymalizować na tej podstawie. Jeśli potrzebujesz zdefiniowanego zawijania, użyj typu bez znaku albo sprawdź zakres przed dodawaniem.

Wykrywanie UB sanitizerami i ostrzeżeniami

Testami nie zdobędziesz pewności co do UB, bo udane uruchomienie niczego nie gwarantuje. Co naprawdę działa, to sprawienie, by UB było głośne w czasie działania, za pomocą sanitizerów kompilatora (dostępnych w GCC i Clang).

// AddressSanitizer: wyjście poza zakres, użycie po zwolnieniu, wycieki
g++ -fsanitize=address -g -O1 main.cpp -o app && ./app

// UndefinedBehaviorSanitizer: przepełnienie ze znakiem, dereferencja null, złe rzutowania
g++ -fsanitize=undefined -g main.cpp -o app && ./app

Uruchom istniejące testy z tymi flagami, a odczyt poza zakresem, użycie po zwolnieniu czy przepełnienie ze znakiem, które "działały bez problemu", zamienią się w precyzyjny raport z nazwą pliku i numerem linii. Połącz je z -Wall -Wextra, żeby kompilator zgłaszał też podejrzany kod (na przykład prawdopodobny odczyt niezainicjalizowanej zmiennej), zanim w ogóle uruchomisz program.

==1234==ERROR: AddressSanitizer: heap-use-after-free on address 0x...
READ of size 4 at 0x... thread T0
    #0 main.cpp:7 in main

Traktuj każdy raport sanitizera jako błąd do obowiązkowej naprawy, a nie ostrzeżenie do zignorowania: mówi ci, że standard niczego nie obiecuje w sprawie tej linii.

Podsumowanie

Niezdefiniowane zachowanie to ta część C++, w której zdejmuje się barierki: dostęp poza zakresem, wiszące wskaźniki, użycie po zwolnieniu, odczyt niezainicjalizowanych zmiennych i przepełnienie ze znakiem dają kod bez zdefiniowanego znaczenia, a "u mnie działało" nigdy nie dowodzi, że jest poprawny. Bezpieczeństwo daje programowanie defensywne: inicjalizuj każdą zmienną, szanuj granice kontenerów, oddaj pamięć na stercie inteligentnym wskaźnikom, a potem weryfikuj za pomocą -fsanitize=address, -fsanitize=undefined oraz -Wall -Wextra, żeby ciche UB stało się głośnym raportem, który da się naprawić.

To zamyka rozdział o błędach i debugowaniu. Dzięki wyjątkom, try/catch i zdrowemu respektowi wobec UB masz teraz narzędzia do pisania kodu w C++, który zawodzi głośno i celowo, a nie po cichu i przypadkiem.