幾周前,我的一位同僚帶着一個程式設計問題來到我桌前。最近我們一直在互相考問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
我自鳴得意地寫下答案後,我的同僚回應了一個簡單的“不”。我想了幾分鐘後,還是被難住了。我不太記得字尾操作符的結合順序了。此外,我知道那個順序甚至不會改變這裡的值計算的順序,因為結合規則隻會應用于同級的操作符之間。但我想到了應該根據字尾操作符都從右到左求值的規則,嘗試算一遍這條算式。看上去相當簡單明了。
// = 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>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 20 sub $0x20,%rsp
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)
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)
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>
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++在這三條指令之前已經運作過了,但也許最後兩條指令會用某種彙編的魔法來得到預期的結果(2a[1])。這兩條指令把eax寄存器的值自加了一次,實際上執行了2a[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語言知識。衆所周知,最好的應用是避免構造複雜的字首字尾表達式,這就是一個關于為什麼要這樣的極好例子。