{"id":1369,"date":"2019-03-27T10:49:23","date_gmt":"2019-03-27T09:49:23","guid":{"rendered":"https:\/\/www.kompikownia.pl\/?p=1369"},"modified":"2019-03-29T13:50:10","modified_gmt":"2019-03-29T12:50:10","slug":"czym-jest-undefined-behavior-w-c-c","status":"publish","type":"post","link":"https:\/\/www.kompikownia.pl\/index.php\/2019\/03\/27\/czym-jest-undefined-behavior-w-c-c\/","title":{"rendered":"Czym jest undefined behavior w C\/C++?"},"content":{"rendered":"Czas czytania:<\/span> 3<\/span> minut<\/span><\/span>\n

Je\u015bli troch\u0119 ju\u017c programowa\u0142e\u015b, z pewno\u015bci\u0105 s\u0142ysza\u0142e\u015b o czym\u015b takim jak undefined behavior – niezdefiniowane zachowanie. Jest to bardzo nieprzyjemna sytuacja, kiedy kompilator nie do ko\u0144ca wie, jak poprawnie si\u0119 zachowa\u0107. Wynika to g\u0142\u00f3wnie ze standardu, w kt\u00f3rym niekt\u00f3re operacje s\u0105 opisane jako niezdefiniowane. Standard C99 definiuje prawie 200 takich sytuacji<\/a>, Niezdefiniowane zachowanie mo\u017ce wynika\u0107 po\u015brednio tak\u017ce ze „sztuczek optymalizacyjnych” zastosowanych przez kompilator.<\/p>\n\n\n\n

Warto wiedzie\u0107 nie tylko o sytuacjach najcz\u0119\u015bciej prowadz\u0105cych do „undefined behavior”, ale tak\u017ce rozumie\u0107 co si\u0119 dzieje po stronie kompilatora. Przeprowadzimy kr\u00f3tk\u0105 analiz\u0119 tej paskudnej cechy j\u0119zyka C\/C++.<\/p>\n\n\n\n

Z czego wynika undefined behavior?<\/h2>\n\n\n\n

Mo\u017cesz zada\u0107 pytanie – po co w standardzie zostawiono jakie\u015b niejasno\u015bci? Dlaczego nie wyja\u015bniono dok\u0142adnie ka\u017cdej mo\u017cliwej sytuacji? Pozostawienie niekt\u00f3rych trudnych do rozpatrzenia niuans\u00f3w „niezdefiniowanymi” pozwala znacznie upro\u015bci\u0107 budow\u0119 kompilator\u00f3w. (Te i tak ze wzgl\u0119du na swoj\u0105 natur\u0119 s\u0105 bardzo skomplikowane). Innym powodem jest potrzeba zachowania kompatybilno\u015bci z jak najwi\u0119ksz\u0105 ilo\u015bci\u0105 architektur. r\u00f3\u017cne architektury procesor\u00f3w posiadaj\u0105 r\u00f3\u017cne mo\u017cliwo\u015bci i r\u00f3\u017cnie interpretuj\u0105 polecenia takie jak przesuni\u0119cie bitowe. Narzucenie z g\u00f3ry jakiego\u015b zachowania w konfliktowej sytuacji, takiej jak dzielenie przez zero mog\u0142oby spowodowa\u0107 du\u017cy narzut na niekt\u00f3rych architekturach CPU. Ponadto, programy s\u0105 szybsze. Dlaczego? <\/p>\n\n\n\n

Sp\u00f3jrzmy na zwyk\u0142\u0105 operacj\u0119 odczytu danego elementu z tablicy. Dzi\u0119ki temu, \u017ce kompilator j\u0119zyka C\/C++ nie sprawdza granic tablicy, odchodzi ca\u0142a zabawa zwi\u0105zana ze sprawdzaniem tego faktu. Program zajmuje mniej miejsca i szybciej si\u0119 wykonuje. Tak samo wygl\u0105da sytuacja z przepe\u0142nieniem zmiennych. Kompilator nie musi martwi\u0107 si\u0119 o to, \u017ce trzeba jako\u015b pozytywnie zareagowa\u0107 na t\u0119 sytuacj\u0119. Zabezpieczeniem przed takimi b\u0142\u0119dami powinien martwi\u0107 si\u0119 programista. <\/p>\n\n\n\n

Nie zapominajmy, \u017ce niekt\u00f3re j\u0119zyki takie jak Java, s\u0105 w tym wzgl\u0119dzie o wiele bardziej restrykcyjne ni\u017c C++. W Javie wszelkie niebezpieczne zachowania prowadz\u0105 do wyrzucenia odpowiednich wyj\u0105tk\u00f3w, kt\u00f3re najcz\u0119\u015bciej przerywaj\u0105 dzia\u0142anie programu (chyba \u017ce programista zadecyduje inaczej. To by\u0142 jeden z powod\u00f3w przez kt\u00f3re na pocz\u0105tku swojej historii Java by\u0142a wolniejsza od j\u0119zyk\u00f3w kompilowanych do kodu maszynowego. W dzisiejszych czasach r\u00f3\u017cnica w wydajno\u015bci jest praktycznie niezauwa\u017calna. <\/p>\n\n\n\n

Dlaczego ignorujemy undefined behavior?<\/h2>\n\n\n\n

Najcz\u0119\u015bciej z powodu braku \u015bwiadomo\u015bci, \u017ce takie a nie inne rozwi\u0105zanie mo\u017ce doprowadzi\u0107 do tragedii. Je\u015bli program wykonuje si\u0119 prawid\u0142owo – go on, przecie\u017c wszystko jest ok. No nie do ko\u0144ca. <\/p>\n\n\n\n

Co mo\u017ce si\u0119 wydarzy\u0107 kiedy napiszemy program wykorzystuj\u0105cy undefined behavior i spr\u00f3bujemy go skompilowa\u0107 a nast\u0119pnie uruchomi\u0107? Dos\u0142ownie wszystko! Program mo\u017ce dzia\u0142a\u0107 ca\u0142kowicie prawid\u0142owo, wyk\u0142adaj\u0105c si\u0119 jedynie w \u015bci\u015ble okre\u015blonych sytuacjach. Aplikacja mo\u017ce si\u0119 uruchomi\u0107. Lecz po uruchomieniu mo\u017ce dzia\u0142a\u0107 \u017ale, b\u0142\u0119dnie wykonuj\u0105c obliczenia. W najlepszej mo\u017cliwej sytuacji kompilator poinformuje nas za pomoc\u0105 ostrze\u017cenia lub b\u0142\u0119du, \u017ce zrobili\u015bmy co\u015b, co mo\u017ce zako\u0144czy\u0107 si\u0119 \u017ale. <\/p>\n\n\n\n

Typy „zachowania”<\/h2>\n\n\n\n

Og\u00f3lnie zachowanie i spos\u00f3b wykonania funkcji\/metod mo\u017cemy podzieli\u0107 na trzy „g\u0142\u00f3wne” rodzaje: <\/p>\n\n\n\n

  • Typ 1<\/strong> – zachowanie jest zdefiniowane dla ka\u017cdego mo\u017cliwego zbioru parametr\u00f3w wej\u015bciowych<\/li>
  • Typ 2 <\/strong>– zachowanie jest zdefiniowane tylko dla niekt\u00f3rych zbior\u00f3w parametr\u00f3w wej\u015bciowych<\/li>
  • Typ 3<\/strong> – zachowanie jest niezdefiniowane dla wszystkich mo\u017cliwych parametr\u00f3w wej\u015bciowych<\/li><\/ul>\n\n\n\n

    Aby nie la\u0107 wody, przeanalizujemy kr\u00f3tko i konkretnie ka\u017cd\u0105 z wymienionych mo\u017cliwo\u015bci. <\/p>\n\n\n\n

    Funkcje typu 1<\/h3>\n\n\n\n

    Funkcje tego typu nigdy nie maj\u0105 problem\u00f3w ze sob\u0105 i zawsze si\u0119 prawid\u0142owo wykonuj\u0105. Sp\u00f3jrz np.: na taki przyk\u0142ad:<\/p>\n\n\n

    1
    2
    3
    4
    5
    6
    7
    8
    <\/div><\/td>
    int<\/span> safeDiv (<\/span>int<\/span> a, int<\/span> b)<\/span> {<\/span>
    \n  if<\/span> (<\/span>(<\/span>b ==<\/span> 0<\/span>)<\/span> ||<\/span> (<\/span>(<\/span>a ==<\/span> INT_MIN<\/span>)<\/span> &&<\/span> (<\/span>b ==<\/span> -<\/span>1<\/span>)<\/span>)<\/span>)<\/span> {<\/span>
    \n    puts<\/span>(<\/span>"Nie wolno tak dzielic!!!"<\/span>)<\/span>;<\/span>
    \n    return<\/span> 0<\/span>;<\/span>
    \n  }<\/span> else<\/span> {<\/span>
    \n    return<\/span> a \/<\/span> b;<\/span>
    \n  }<\/span>
    \n}<\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n\n\n

    Z lekcji matematyki wiemy, \u017ce nie wolno dzieli\u0107 przez 0. Zabezpieczyli\u015bmy tak\u017ce program przed przepe\u0142nieniem zmiennej. Odpowiada za to druga cz\u0119\u015b\u0107 warunku. <\/p>\n\n\n\n

    W sumie, omawiaj\u0105c temat niezdefiniowanego zachowania tego typu funkcje nie s\u0105 dla nas ciekawe. <\/p>\n\n\n\n

    Funkcje typu 3<\/h3>\n\n\n\n

    Funkcje tego typu w ka\u017cdym wypadku mog\u0105 spowodowa\u0107 dziwne zachowanie. Prostym przyk\u0142adem jest niepoprawnie zastosowany operator przesuni\u0119cia arytmetycznego.<\/p>\n\n\n

    1
    2
    3
    4
    5
    6
    7
    8
    9
    <\/div><\/td>
    #include <iostream><\/span>
    \nusing<\/span> namespace<\/span> std;<\/span>
    \nint<\/span> main(<\/span>)<\/span>
    \n{<\/span>
    \n    int<\/span> a =<\/span> 1<\/span>;<\/span>
    \n    a=<\/span>a<<<\/span>32<\/span>;<\/span>
    \n    cout<\/span><<<\/span>a<<<\/span>endl;<\/span>
    \n    return<\/span> 0<\/span>;<\/span>
    \n}<\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n\n\n

    Teoretycznie program nie wykonuje \u017cadnych niepo\u017c\u0105danych operacji. Mo\u017cna rzec – jest prosty jak budowa cepa. Jego jedynym efektem powinno by\u0107 przesuni\u0119cie bitowe warto\u015bci zmiennej a o 32 bity w lewo. <\/p>\n\n\n\n

    Jakiego wyniku si\u0119 spodziewamy? Wydaje si\u0119, \u017ce program powinien wy\u015bwietli\u0107 liczb\u0119 0. Przewidujemy taki rezultat, gdy\u017c skrajne bity s\u0105 tracone przy przesuni\u0119ciu. Przesuwamy o 32 bity, a wi\u0119c o wi\u0119ksz\u0105 ilo\u015b\u0107 ni\u017c wynosi rozmiar zmiennej int. Z tego za\u0142o\u017cenia wynika \u017ce wszystkie bity powinny by\u0107 stracone a ostateczna warto\u015b\u0107 zmiennej powinna wynosi\u0107 0. <\/p>\n\n\n\n

    Kompilujemy i uruchamiamy program i … <\/p>\n\n\n\n

    \"wynik<\/figure><\/div>\n\n\n\n

    zonk. Warto\u015b\u0107 wynosi 1. Dlaczego? Zajrzyjmy do standardu j\u0119zyka C:<\/p>\n\n\n\n

    The result is undefined if the right operand is negative, or greater than or equal to the number of bits in the left expression\u2019s type.<\/p>\n\n\n\n

    A teraz zerknijmy jeszcze na dokumentacj\u0119 procesora 8086 – przodka wszystkich wsp\u00f3\u0142czesnych CPU architektury x86. <\/p>\n\n\n\n

    The 8086 does not mask the shift count. However, all other IA-32 processors (starting with the Intel 286 processor) do mask the shift count to 5 bits, resulting in a maximum count of 31. This masking is done in all operating modes (including the virtual-8086 mode) to reduce the maximum execution time of the instructions.<\/p>\n\n\n\n

    Jak widzisz, taki a nie inny wynik dzia\u0142ania programu zale\u017cy w tym wypadku wy\u0142\u0105cznie od zachowania procesora, a nie od woli programisty. Aby udowodni\u0107, \u017ce powy\u017cszy program mo\u017ce zachowywa\u0107 si\u0119 r\u00f3\u017cnie w zale\u017cno\u015bci od architektury CPU uruchommy go na Raspberry PI – typowym przedstawicielu architektury ARM. <\/p>\n\n\n\n

    \"\"<\/figure><\/div>\n\n\n\n

    Tym razem identyczny<\/strong> program zwr\u00f3ci\u0142 warto\u015b\u0107 0. Dowodzi to, \u017ce musimy uwa\u017ca\u0107 na dzia\u0142ania, kt\u00f3re s\u0105 okre\u015blone jako „undefined”.<\/p>\n\n\n\n

    Funkcje typu 2<\/h3>\n\n\n\n

    Dla tych funkcji „undefined behavior” mo\u017ce wyst\u0105pi\u0107 tylko dla niekt\u00f3rych danych wej\u015bciowych. Jest to najciekawszy przypadek dla nas. Jednocze\u015bnie takie b\u0142\u0119dy najtrudniej zauwa\u017cy\u0107. Przeanalizujmy co robi funkcja f w poni\u017cszym listingu. <\/p>\n\n\n\n\n

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    <\/div><\/td>
    #include <iostream><\/span>
    \n#include <limits.h><\/span>
    \nusing<\/span> namespace<\/span> std;<\/span>
    \nint<\/span> f(<\/span>int<\/span> i)<\/span> {<\/span>
    \n    return<\/span> i+<\/span>1<\/span> ><\/span> i;<\/span>
    \n}<\/span>
    \nint<\/span> main(<\/span>)<\/span>
    \n{<\/span>
    \n    int<\/span> a =<\/span> 1<\/span>;<\/span>
    \n    int<\/span> b =<\/span> f(<\/span>a)<\/span>;<\/span>
    \n    cout<\/span><<<\/span>b<<<\/span>endl;<\/span>
    \n    return<\/span> 0<\/span>;<\/span>
    \n}<\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n\n\n\n

    Potencjalnie nie widzimy nic niebezpiecznego ani wieloznacznego. Funkcja wykonuje bardzo prost\u0105 operacj\u0119. Sprawdzamy czy warto\u015b\u0107 parametru zwi\u0119kszona o jeden jest wi\u0119ksza od tego parametru. Wydaje si\u0119, \u017ce powinna ona zawsze zwr\u00f3ci\u0107 warto\u015b\u0107 1. W ko\u0144cu ka\u017cda liczba jest mniejsza od tej samej liczby powi\u0119kszonej o 1, prawda? Ale nie jest to takie proste m\u00f3j kamracie. Zauwa\u017c, \u017ce je\u015bli przeka\u017cemy jako argument INT_MAX (czyli maksymaln\u0105 warto\u015b\u0107, jak\u0105 mo\u017ce pomie\u015bci\u0107 typ int) i zwi\u0119kszymy j\u0105 o 1 otrzymamy liczb\u0119 du\u017co mniejsz\u0105. Wtedy funkcja ta zwr\u00f3ci false. <\/p>\n\n\n\n

    Je\u015bli skompilujemy program z t\u0105 funkcj\u0105 bez w\u0142\u0105czonych optymalizacji za pomoc\u0105 kompilatora gcc, nie nast\u0105pi\u0105 \u017cadne problemy. Aplikacja b\u0119dzie dzia\u0142a\u0142a prawid\u0142owo dla ka\u017cdego przypadku. Nawet wtedy, gdy jako argument tej funkcji podamy warto\u015b\u0107 INT_MAX. Sp\u00f3jrzmy na kod assemblera, kt\u00f3ry zosta\u0142 wygenerowany w finalnym pliku wykonywalnym:<\/p>\n\n\n

    push<\/span>   rbp<\/span>
    \nmov<\/span>    rbp<\/span>,<\/span>rsp<\/span>
    \nmov<\/span>    DWORD<\/span> PTR [<\/span>rbp<\/span>-<\/span>0x4<\/span>]<\/span>,<\/span>edi<\/span>
    \nmov<\/span>    eax<\/span>,<\/span>DWORD<\/span> PTR [<\/span>rbp<\/span>-<\/span>0x4<\/span>]<\/span>
    \nadd<\/span>    eax<\/span>,<\/span>0x1<\/span>
    \ncmp<\/span>    eax<\/span>,<\/span>DWORD<\/span> PTR [<\/span>rbp<\/span>-<\/span>0x4<\/span>]<\/span>
    \nsetg<\/span>   al<\/span>
    \nmovzx<\/span>  eax<\/span>,<\/span>al<\/span>
    \npop<\/span>    rbp<\/span>
    \nret<\/span><\/div><\/div>\n\n\n\n

    Kod wygl\u0105da tak jak przypuszczali\u015bmy. W rejestrze EAX przechowywany jest argument funkcji. Zwi\u0119kszamy ten argument o 1 i por\u00f3wnujemy. Zwracamy wynik por\u00f3wnania. Kompilator wygenerowa\u0142 zbi\u00f3r takich instrukcji, jakich oczekiwali\u015bmy. Jednak\u017ce co si\u0119 stanie, gdy w\u0142\u0105czymy optymalizacj\u0119 na maksymalnym poziomie: O3? Co si\u0119 zmieni\u0142o w kodzie ASM?<\/p>\n\n\n

    mov<\/span>    eax<\/span>,<\/span>0x1<\/span>
    \nret<\/span><\/div><\/div>\n\n\n\n

    Hmmm. Kompilator na pewno optymalizowa\u0142 ten kod. Mo\u017cemy powiedzie\u0107, \u017ce nawet przesadzi\u0142 z optymalizacj\u0105, gdy\u017c wywali\u0142 ca\u0142kowicie sprawdzanie warunku mniejsze\/wi\u0119ksze. Widocznie uzna\u0142, \u017ce jeden przypadek, kiedy funkcja zwraca inn\u0105 warto\u015b\u0107 ni\u017c 1 mo\u017cna pomin\u0105\u0107 … Ta optymalizacja powoduje, \u017ce program dla INT_MAX zwr\u00f3ci inny wynik ni\u017c ten kt\u00f3rego by\u015bmy oczekiwali. Mo\u017cesz nie rozumie\u0107 kodu ASM, wi\u0119c przedstawi\u0119 jak wygl\u0105da\u0142aby funkcja f w postaci zoptymalizowanej prze kompilator:<\/p>\n\n\n

    int<\/span> f(<\/span>int<\/span> i)<\/span> {<\/span>
    \n    return<\/span> 1<\/span>;<\/span>
    \n}<\/span><\/div><\/div>\n\n\n\n

    Prawda, \u017ce nie o to nam chodzi\u0142o? A jak standard zapatruje si\u0119 na to, co przed chwil\u0105 si\u0119 wydarzy\u0142o? Ot\u00f3\u017c – jest to standardowy przypadek tzw. „integer overflow”.<\/p>\n\n\n\n

    If an exceptional condition<\/em> occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.<\/p>\n\n\n\n

    No c\u00f3\u017c. Jedynym rozwi\u0105zaniem jest dodanie instrukcji warunkowej zabezpieczaj\u0105cej program przed podaniem argumentu INT_MAX, a tym samym przed przepe\u0142nieniem zmiennej integer. <\/p>\n\n\n\n

    Jak zapobiega\u0107 undefined behavior?<\/h2>\n\n\n\n

    Undefined behavior jest czym\u015b takim, czego powinni\u015bmy unika\u0107 za wszelk\u0105 cen\u0119. B\u0142\u0119dy tego rodzaju s\u0105 nierzadko bardzo ci\u0119\u017ckie do zdebugowania i wykrycia. Zdarzaj\u0105 si\u0119 sytuacje, kiedy aplikacja pod debuggerem wykonuje si\u0119 prawid\u0142owo, a samodzielnie sypie b\u0142\u0119dami … Naprawd\u0119 zatruwa to \u017cycie programisty. Dlatego warto wiedzie\u0107 sk\u0105d bierze si\u0119 undefined behavior. A jak mo\u017cemy mu zapobiec? <\/p>\n\n\n\n