C語言未定義行為分析

這篇文章主要介紹“C語言未定義行為分析”，在日常操作中，相信很多人在C語言未定義行為分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”C語言未定義行為分析”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

他在白板上寫了幾行代碼，并問這個程序會輸出什么？

#include <stdio.h>   int main(){     int i = 0;     int a[] = {10,20,30};       int r = 1 * a[i++] + 2 * a[i++] + 3 * a[i++];     printf("%d\n", r);     return 0; }

看上去相當簡單明了。我解釋了操作符的優先順序——后綴操作比乘法先計算、乘法比加法先計算，并且乘法和加法的結合性都是從左到右，于是我抓出運算符號并開始寫出算式。

int r = 1 * a[i++] + 2 * a[i++] + 3 * a[i++]; //    =    a[0]    + 2 * a[1]  + 3 * a[2]; //    =     10     +     40    +    90; //    = 140

我自鳴得意地寫下答案后，我的同事回應了一個簡單的“不”。我想了幾分鐘后，還是被難住了。我不太記得后綴操作符的結合順序了。此外，我知道那個順 序甚至  不會改變這里的值計算的順序，因為結合規則只會應用于同級的操作符之間。但我想到了應該根據后綴操作符都從右到左求值的規則，嘗試算一遍這條算式。看上去  相當簡單明了。

int r = 1 * a[i++] + 2 * a[i++] + 3 * a[i++]; //    =    a[2]    + 2 * a[1]  + 3 * a[0]; //    =     30     +     40    +    30; //    = 100

我的同事再一次回答說，答案仍是錯的。這時候我只好認輸了，問他答案是什么。這段短小的樣例代碼原來是從他寫過的更大的代碼段里刪減出來的。為了驗   證他的問題，他編譯并且運行了那個更大的代碼樣例，但是驚奇地發現那段代碼沒有按照他預想的運行。他刪減了不需要的步驟后得到了上面的樣例代碼，用gcc   4.7.3編譯了這段樣例代碼，結果輸出了令人吃驚的結果：“60”。

這時我被迷住了。我記得，C語言里，函數參數的計算求值順序是未定義的，所以我們以為后綴操作符只是遵照某個隨機的、而非從左至右的順序，計算的。   我們仍然確信后綴比加法和乘法擁有更高的操作優先級，所以很快證明我們自己，不存在我們可以計算i++的順序，使得這三個數組元素一起加起來、乘起來得到  60。

現在我已對此入迷了。我的***個想法是，查看這段代碼的反匯編代碼，然后嘗試查出它實際上發生了什么。我用調試符號（debugging symbols）編譯了這段樣例代碼，用了objdump后很快得到了帶注釋的x86_64反匯編代碼。

Disassembly of section .text:   0000000000000000 <main>: #include <stdio.h>   int main(){    0:   55                      push   %rbp    1:   48 89 e5                mov    %rsp,%rbp    4:   48 83 ec 20             sub    $0x20,%rsp     int i = 0;    8:   c7 45 e8 00 00 00 00    movl   $0x0,-0x18(%rbp)     int a[] = {10,20,30};    f:   c7 45 f0 0a 00 00 00    movl   $0xa,-0x10(%rbp)   16:   c7 45 f4 14 00 00 00    movl   $0x14,-0xc(%rbp)   1d:   c7 45 f8 1e 00 00 00    movl   $0x1e,-0x8(%rbp)     int r = 1 * a[i++] + 2 * a[i++] + 3 * a[i++];   24:   8b 45 e8                mov    -0x18(%rbp),%eax   27:   48 98                   cltq    29:   8b 54 85 f0             mov    -0x10(%rbp,%rax,4),%edx   2d:   8b 45 e8                mov    -0x18(%rbp),%eax   30:   48 98                   cltq    32:   8b 44 85 f0             mov    -0x10(%rbp,%rax,4),%eax   36:   01 c0                   add    %eax,%eax   38:   8d 0c 02                lea    (%rdx,%rax,1),%ecx   3b:   8b 45 e8                mov    -0x18(%rbp),%eax   3e:   48 98                   cltq    40:   8b 54 85 f0             mov    -0x10(%rbp,%rax,4),%edx   44:   89 d0                   mov    %edx,%eax   46:   01 c0                   add    %eax,%eax   48:   01 d0                   add    %edx,%eax   4a:   01 c8                   add    %ecx,%eax   4c:   89 45 ec                mov    %eax,-0x14(%rbp)   4f:   83 45 e8 01             addl   $0x1,-0x18(%rbp)   53:   83 45 e8 01             addl   $0x1,-0x18(%rbp)   57:   83 45 e8 01             addl   $0x1,-0x18(%rbp)     printf("%d\n", r);   5b:   8b 45 ec                mov    -0x14(%rbp),%eax   5e:   89 c6                   mov    %eax,%esi   60:   bf 00 00 00 00          mov    $0x0,%edi   65:   b8 00 00 00 00          mov    $0x0,%eax   6a:   e8 00 00 00 00          callq  6f <main+0x6f>     return 0;   6f:   b8 00 00 00 00          mov    $0x0,%eax }   74:   c9                      leaveq   75:   c3                      retq

***和***的幾個指令只建立了堆棧結構，初始化變量的值，調用printf函數，還從main函數返回。所以我們實際上只需要關心從0×24到0×57之間的指令。那是令人關注的行為發生的地方。讓我們每次查看幾個指令。

24:   8b 45 e8                mov    -0x18(%rbp),%eax 27:   48 98                   cltq  29:   8b 54 85 f0             mov    -0x10(%rbp,%rax,4),%edx

***的三個指令與我們預期的一致。首先，它把i(0)的值加載到eax寄存器，帶符號擴展到64位，然后加載a[0]到edx寄存器。這里的乘以1的運算（1*）顯然被編譯器優化后去除了，但是一切看起來都正常。接下來的幾個指令開始時也大致相同。

2d:   8b 45 e8                mov    -0x18(%rbp),%eax 30:   48 98                   cltq  32:   8b 44 85 f0             mov    -0x10(%rbp,%rax,4),%eax 36:   01 c0                   add    %eax,%eax 38:   8d 0c 02                lea    (%rdx,%rax,1),%ecx

***個mov指令把i的值（仍然是0）加載進eax寄存器，帶符號擴展到64位，然后加載a[0]進eax寄存器。有意思的事情發生了——我們再次 期待  i++在這三條指令之前已經運行過了，但也許***兩條指令會用某種匯編的魔法來得到預期的結果(2*a[1]）。這兩條指令把eax寄存器的值自加了一  次，實際上執行了2*a[0]的操作，然后把結果加到前面的計算結果上，并存進ecx寄存器。此時指令已經求得了a[0] + 2 *   a[0]的值。事情開始看起來有一些奇怪了，然而再一次，也許某個編譯器魔法在發生。

3b:   8b 45 e8                mov    -0x18(%rbp),%eax 3e:   48 98                   cltq  40:   8b 54 85 f0             mov    -0x10(%rbp,%rax,4),%edx 44:   89 d0                   mov    %edx,%eax

接下來這些指令開始看上去相當熟悉。他們加載i的值（仍然是0），帶符號擴展至64位，加載a[0]到edx寄存器，然后拷貝edx里的值到eax。嗯，好吧，讓我們在多看一些：

46:   01 c0                   add    %eax,%eax 48:   01 d0                   add    %edx,%eax 4a:   01 c8                   add    %ecx,%eax 4c:   89 45 ec                mov    %eax,-0x14(%rbp)

在這里把a[0]自加了3次，再加上之前的計算結果，然后存入到變量“r”。現在不可思議的事情——我們的變量r現在包含了a[0] + 2 *   a[0] + 3 * a[0]。足夠肯定的是，那就是程序的輸出：“60”。但是那些后綴操作符上發生了什么？他們都在***：

4f:   83 45 e8 01             addl   $0x1,-0x18(%rbp) 53:   83 45 e8 01             addl   $0x1,-0x18(%rbp) 57:   83 45 e8 01             addl   $0x1,-0x18(%rbp)

看上去我們編譯版本的代碼完全錯了！為什么后綴操作符被扔到***下、所有任務已經完成之后？隨著我對現實的信仰減少，我決定直接去找本源。不，不是編譯器的源代碼——那只是實現——我抓起了C11語言規范。

這個問題處在后綴操作符的細節。在我們的案例中，我們在單個表達式里對數組下標執行了三次后綴自增。當計算后綴操作符時，它返回變量的初始值。把新   的值再分配回變量是一個副作用。結果是，那個副作用只被定義為只被付諸于各順序點之間。參照標準的5.1.2.3章節，那里定義了順序點的細節。但在我們  的例子中，我們的表達式展示了未定義行為。它完全取決于編譯器對于 什么時候 給變量分配新值的副作用會執行 相對于表達式的其他部分。

到此，關于“C語言未定義行為分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！