C語言全局變量那些事兒
作為一名程序員，如果說沉迷一門編程語言算作一種樂趣的話，那么與此同時(shí)反過來去黑一門編程語言就是這種樂趣的升華。今天我們就來黑一把C語言，好好展示一下這門經(jīng)典語言令人抓狂的一面。
我們知道，全局變量是C語言語法和語義中一個(gè)很重要的知識(shí)點(diǎn)，首先它的存在意義需要從三個(gè)不同角度去理解：對(duì)于程序員來說，它是一個(gè)記錄內(nèi)容的變量(variable)；對(duì)于編譯/鏈接器來說，它是一個(gè)需要解析的符號(hào)(symbol)；對(duì)于計(jì)算機(jī)來說，它可能是具有地址的一塊內(nèi)存(memory)。其次是語法/語義：從作用域上看，帶static關(guān)鍵字的全局變量范圍只能限定在文件里，否則會(huì)外聯(lián)到整個(gè)模塊和項(xiàng)目中；從生存期來看，它是靜態(tài)的，貫穿整個(gè)程序或模塊運(yùn)行期間（注意，正是跨單元訪問和持續(xù)生存周期這兩個(gè)特點(diǎn)使得全局變量往往成為一段受攻擊代碼的突破口，了解這一點(diǎn)十分重要）；從空間分配上看，定義且初始化的全局變量在編譯時(shí)在數(shù)據(jù)段(.data)分配空間，定義但未初始化的全局變量暫存(tentative definition)在.bss段，編譯時(shí)自動(dòng)清零，而僅僅是聲明的全局變量只能算個(gè)符號(hào)，寄存在編譯器的符號(hào)表內(nèi)，不會(huì)分配空間，直到鏈接或者運(yùn)行時(shí)再重定向到相應(yīng)的地址上。
我們將向您展現(xiàn)一下，非static限定全局變量在編譯/鏈接以及程序運(yùn)行時(shí)會(huì)發(fā)生哪些有趣的事情，順便可以對(duì)C編譯器/鏈接器的解析原理管中窺豹。以下示例對(duì)ANSI C和GNU C標(biāo)準(zhǔn)都有效，筆者的編譯環(huán)境是Ubuntu下的GCC-4.4.3。
- /* t.h */
- #ifndef _H_
- #define _H_
- int a;
- #endif
- /* foo.c */
- #include <stdio.h>
- #include "t.h"
- struct {
- char a;
- int b;
- } b = { 2, 4 };
- int main();
- void foo()
- {
- printf("foo:\t(&a)=0x%08x\n\t(&b)=0x%08x\n
- \tsizeof(b)=%d\n\tb.a=%d\n\tb.b=%d\n\tmain:0x%08x\n",
- &a, &b, sizeof b, b.a, b.b, main);
- }
- /* main.c */
- #include <stdio.h>
- #include "t.h"
- int b;
- int c;
- int main()
- {
- foo();
- printf("main:\t(&a)=0x%08x\n\t(&b)=0x%08x\n
- \t(&c)=0x%08x\n\tsize(b)=%d\n\tb=%d\n\tc=%d\n",
- &a, &b, &c, sizeof b, b, c);
- return 0;
- }
Makefile如下：
- test: main.o foo.o
- gcc -o test main.o foo.o
- main.o: main.c
- foo.o: foo.c
- clean:
- rm *.o test
運(yùn)行情況：
- foo: (&a)=0x0804a024
- (&b)=0x0804a014
- sizeof(b)=8
- b.a=2
- b.b=4
- main:0x080483e4
- main: (&a)=0x0804a024
- (&b)=0x0804a014
- (&c)=0x0804a028
- size(b)=4
- b=2
- c=0
這個(gè)項(xiàng)目里我們定義了四個(gè)全局變量，t.h頭文件定義了一個(gè)整型a，main.c里定義了兩個(gè)整型b和c并且未初始化，foo.c里定義了一個(gè)初始化了的 結(jié)構(gòu)體，還定義了一個(gè)main的函數(shù)指針變量。由于C語言每個(gè)源文件單獨(dú)編譯，所以t.h分別包含了兩次，所以int a就被定義了兩次。兩個(gè)源文件里變量b和函數(shù)指針變量main被重復(fù)定義了，實(shí)際上可以看做代碼段的地址。但編譯器并未報(bào)錯(cuò)，只給出一條警告：
- /usr/bin/ld: Warning: size of symbol 'b' changed from 4 in main.o to 8 in foo.o
運(yùn)行程序發(fā)現(xiàn)，main.c打印中b大小是4個(gè)字節(jié)，而foo.c是8個(gè)字節(jié)，因?yàn)閟izeof關(guān)鍵字是編譯時(shí)決議，而源文件中對(duì)b類型定義不一 樣。但令人驚奇的是無論是在main.c還是foo.c中，a和b都是相同的地址，也就是說，a和b被定義了兩次，b還是不同類型，但內(nèi)存映像中只有一份 拷貝。我們還看到，main.c中b的值居然就是foo.c中結(jié)構(gòu)體第一個(gè)成員變量b.a的值，這證實(shí)了前面的推斷——即便存在多次定義，內(nèi)存中只有一份初始化的拷貝。另外在這里c是置身事外的一個(gè)獨(dú)立變量。
為何會(huì)這樣呢？這涉及到C編譯器對(duì)多重定義的全局符號(hào)的解析和鏈接。在編譯階段，編譯器將全局符號(hào)信息隱含地編碼在可重定位目標(biāo)文件的符號(hào)表里。這里有個(gè)“強(qiáng)符號(hào)(strong)”和“弱符號(hào)(weak)”的概念——前者指的是定義并且初始化了的變量，比如foo.c里的結(jié)構(gòu)體b，后者指的是未定義或者定義但未初始化的變量，比如main.c里的整型b和c，還有兩個(gè)源文件都包含頭文件里的a。當(dāng)符號(hào)被多重定義時(shí)，GNU鏈接器(ld)使用以下規(guī)則決議：
- 不允許出現(xiàn)多個(gè)相同強(qiáng)符號(hào)。
- 如果有一個(gè)強(qiáng)符號(hào)和多個(gè)弱符號(hào)，則選擇強(qiáng)符號(hào)。
- 如果有多個(gè)弱符號(hào)，那么先決議到size最大的那個(gè)，如果同樣大小，則按照鏈接順序選擇第一個(gè)。
像上面這個(gè)例子中，全局變量a和b存在重復(fù)定義。如果我們將main.c中的b初始化賦值，那么就存在兩個(gè)強(qiáng)符號(hào)而違反了規(guī)則一，編譯器報(bào)錯(cuò)。如果 滿足規(guī)則二，則僅僅提出警告，實(shí)際運(yùn)行時(shí)決議的是foo.c中的強(qiáng)符號(hào)。而變量a都是弱符號(hào)，所以只選擇一個(gè)（按照目標(biāo)文件鏈接時(shí)的順序）。
事實(shí)上，這種規(guī)則是C語言里的一個(gè)大坑，編譯器對(duì)這種全局變量多重定義的“縱容”很可能會(huì)無端修改某個(gè)變量，導(dǎo)致程序不確定行為。如果你還沒有意識(shí)到事態(tài)嚴(yán)重性，我再舉個(gè)例子。
#p#
第二個(gè)例子
- /* foo.c */
- #include <stdio.h>;
- struct {
- int a;
- int b;
- } b = { 2, 4 };
- int main();
- void foo()
- {
- printf("foo:\t(&b)=0x%08x\n\tsizeof(b)=%d\n
- \tb.a=%d\n\tb.b=%d\n\tmain:0x%08x\n",
- &b, sizeof b, b.a, b.b, main);
- }
- /* main.c */
- #include <stdio.h>
- int b;
- int c;
- int main()
- {
- if (0 == fork()) {
- sleep(1);
- b = 1;
- printf("child:\tsleep(1)\n\t(&b):0x%08x\n
- \t(&c)=0x%08x\n\tsizeof(b)=%d\n\tset b=%d\n\tc=%d\n",
- &b, &c, sizeof b, b, c);
- foo();
- } else {
- foo();
- printf("parent:\t(&b)=0x%08x\n\t(&c)=0x%08x\n
- \tsizeof(b)=%d\n\tb=%d\n\tc=%d\n\twait child...\n",
- &b, &c, sizeof b, b, c);
- wait(-1);
- printf("parent:\tchild over\n\t(&b)=0x%08x\n
- \t(&c)=0x%08x\n\tsizeof(b)=%d\n\tb=%d\n\tc=%d\n",
- &b, &c, sizeof b, b, c);
- }
- return 0;
- }
運(yùn)行情況如下：
- foo: (&b)=0x0804a020
- sizeof(b)=8
- b.a=2
- b.b=4
- main:0x080484c8
- parent: (&b)=0x0804a020
- (&c)=0x0804a034
- sizeof(b)=4
- b=2
- c=0
- wait child...
- child: sleep(1)
- (&b):0x0804a020
- (&c)=0x0804a034
- sizeof(b)=4
- set b=1
- c=0
- foo: (&b)=0x0804a020
- sizeof(b)=8
- b.a=1
- b.b=4
- main:0x080484c8
- parent: child over
- (&b)=0x0804a020
- (&c)=0x0804a034
- sizeof(b)=4
- b=2
- c=0
（說明一點(diǎn)，運(yùn)行情況是直接輸出到stdout的打印，筆者曾經(jīng)將./test輸出重定向到log中，結(jié)果發(fā)現(xiàn)打印的執(zhí)行序列不一致，所以采用默認(rèn)輸出。）
這是一個(gè)多進(jìn)程環(huán)境，首先我們看到無論父進(jìn)程還是子進(jìn)程，main.c還是foo.c，全局變量b和c的地址仍然是一致的（當(dāng)然只是個(gè)邏輯地址），而且對(duì)b的大小不同模塊仍然有不同的決議。這里值得注意的是，我們?cè)谧舆M(jìn)程中對(duì)變量b進(jìn)行賦值動(dòng)作，從此子進(jìn)程本身包括foo()調(diào)用中，整型b以及結(jié)構(gòu)體成員b.a的值都是1，而父進(jìn)程中整型b和結(jié)構(gòu)體成員b.a的值仍是2，但它們顯示的邏輯地址仍是一致的。
個(gè)人認(rèn)為可以這樣解釋，fork創(chuàng)建新進(jìn)程時(shí)，子進(jìn)程獲得了父進(jìn)程上下文“鏡像”（自然包括全局變量），虛擬地址相同但屬于不同的進(jìn)程空間，而且此時(shí)真正映射的物理地址中只有一份拷貝，所以b的值是相同的（都是2）。隨后子進(jìn)程對(duì)b改寫，觸發(fā)了操作系統(tǒng)的寫時(shí)拷貝(copy on write)機(jī)制，這時(shí)物理內(nèi)存中才產(chǎn)生真正的兩份拷貝，分別映射到不同進(jìn)程空間的虛擬地址上，但虛擬地址的值本身仍然不變，這對(duì)于應(yīng)用程序來說是透明的，具有隱瞞性。
還有一點(diǎn)值得注意，這個(gè)示例編譯時(shí)沒有出現(xiàn)第一個(gè)示例的警告，即對(duì)變量b的sizeof決議，筆者也不知道為什么，或許是GCC的一個(gè)bug？
#p#
第三個(gè)例子
這個(gè)例子代碼同上一個(gè)一致，只不過我們將foo.c做成一個(gè)靜態(tài)鏈接庫libfoo.a進(jìn)行鏈接，這里只給出Makefile的改動(dòng)。
- test: main.o foo.o
- ar rcs libfoo.a foo.o
- gcc -static -o test main.o libfoo.a
- main.o: main.c
- foo.o: foo.c
- clean:
- rm -f *.o test
運(yùn)行情況如下：
- foo: (&b)=0x080ca008
- sizeof(b)=8
- b.a=2
- b.b=4
- main:0x08048250
- parent: (&b)=0x080ca008
- (&c)=0x080cc084
- sizeof(b)=4
- b=2
- c=0
- wait child...
- child: sleep(1)
- (&b):0x080ca008
- (&c)=0x080cc084
- sizeof(b)=4
- set b=1
- c=0
- foo: (&b)=0x080ca008
- sizeof(b)=8
- b.a=1
- b.b=4
- main:0x08048250
- parent: child over
- (&b)=0x080ca008
- (&c)=0x080cc084
- sizeof(b)=4
- b=2
- c=0
從這個(gè)例子看不出有啥差別，只不過使用靜態(tài)鏈接后，全局變量加載的地址有所改變，b和c的地址之間似乎相隔更遠(yuǎn)了些。不過這次編譯器倒是給出了變量b的sizeof決議警告。
到此為止，有些人可能會(huì)對(duì)上面的例子嗤之以鼻，覺得這不過是列舉了C語言的某些特性而已，算不上黑。有些人認(rèn)為既然如此，對(duì)于一切全局變量要么用 static限死，要么定義同時(shí)初始化，杜絕弱符號(hào)，以便在編譯時(shí)報(bào)錯(cuò)檢測(cè)出來。只要小心地使用，C語言還是很完美的嘛~對(duì)于抱這樣想法的人，我只想說， 請(qǐng)你在夜深人靜的時(shí)候豎起耳朵仔細(xì)聆聽，你很可能聽到Dennis Richie在九泉之下邪惡的笑聲——不，與其說是嘲笑，不如說是詛咒……
#p#
第四個(gè)例子
- /* foo.c */
- #include <stdio.h>
- const struct {
- int a;
- int b;
- } b = { 3, 3 };
- int main();
- void foo()
- {
- b.a = 4;
- b.b = 4;
- printf("foo:\t(&b)=0x%08x\n\tsizeof(b)=%d\n
- \tb.a=%d\n\tb.b=%d\n\tmain:0x%08x\n",
- &b, sizeof b, b.a, b.b, main);
- }
- /* t1.c */
- #include <stdio.h>
- int b = 1;
- int c = 1;
- int main()
- {
- int count = 5;
- while (count-- > 0) {
- t2();
- foo();
- printf("t1:\t(&b)=0x%08x\n\t(&c)=0x%08x\n
- \tsizeof(b)=%d\n\tb=%d\n\tc=%d\n",
- &b, &c, sizeof b, b, c);
- sleep(1);
- }
- return 0;
- }
- /* t2.c */
- #include <stdio.h>
- int b;
- int c;
- int t2()
- {
- printf("t2:\t(&b)=0x%08x\n\t(&c)=0x%08x\n
- \tsizeof(b)=%d\n\tb=%d\n\tc=%d\n",
- &b, &c, sizeof b, b, c);
- return 0;
- }
Makefile腳本：
- export LD_LIBRARY_PATH:=.
- all: test
- ./test
- test: t1.o t2.o
- gcc -shared -fPIC -o libfoo.so foo.c
- gcc -o test t1.o t2.o -L. -lfoo
- t1.o: t1.c
- t2.o: t2.c
- .PHONY:clean
- clean:
- rm -f *.o *.so test*
執(zhí)行結(jié)果：
- ./test
- t2: (&b)=0x0804a01c
- (&c)=0x0804a020
- sizeof(b)=4
- b=1
- c=1
- foo: (&b)=0x0804a01c
- sizeof(b)=8
- b.a=4
- b.b=4
- main:0x08048564
- t1: (&b)=0x0804a01c
- (&c)=0x0804a020
- sizeof(b)=4
- b=4
- c=4
- t2: (&b)=0x0804a01c
- (&c)=0x0804a020
- sizeof(b)=4
- b=4
- c=4
- foo: (&b)=0x0804a01c
- sizeof(b)=8
- b.a=4
- b.b=4
- main:0x08048564
- t1: (&b)=0x0804a01c
- (&c)=0x0804a020
- sizeof(b)=4
- b=4
- c=4
- ...
其實(shí)前面幾個(gè)例子只是開胃小菜而已，真正的大坑終于出現(xiàn)了！而且這次編譯器既沒報(bào)錯(cuò)也沒警告，但我們確實(shí)眼睜睜地看到作為main()中強(qiáng)符號(hào)的b 被改寫了，而且一旁的c也“躺槍”了。眼尖的讀者發(fā)現(xiàn)，這次foo.c是作為動(dòng)態(tài)鏈接庫運(yùn)行時(shí)加載的，當(dāng)t1第一次調(diào)用t2時(shí)，libfoo.so還未加 載，一旦調(diào)用了foo函數(shù)，b立馬中彈，而且c的地址居然還相鄰著b，這使得c一同中彈了。不過筆者有些無法解釋這種行為的原因，有種說法是強(qiáng)符號(hào)的全局變量在數(shù)據(jù)段中是連續(xù)分布的（相應(yīng)地弱符號(hào)暫存在.bss段或者符號(hào)表里），或許可以上報(bào)GNU的編譯器開發(fā)小組。
另外筆者嘗試過將t1.c中的b和c定義前面加上const限定詞，編譯器仍然默認(rèn)通過，但程序在main()中第一次調(diào)用foo()時(shí)觸發(fā)了Segment fault異常導(dǎo)致奔潰，在foo.c里使用指針改寫它也一樣。推斷這是GCC對(duì)const常量所在地址啟用了類似操作系統(tǒng)寫保護(hù)機(jī)制，但我無法確定早期版本的GCC是否會(huì)讓這個(gè)const常量被改寫而程序不會(huì)奔潰。
至于volatile關(guān)鍵詞之于全局變量，自測(cè)似乎沒有影響。
怎么樣？看了最后一個(gè)例子是否有點(diǎn)“不明覺厲”呢？C語言在你心目中是否還是當(dāng)初那個(gè)“純潔”、“干凈”、“行為一致”的姑娘呢？也許趁著你不注意 的時(shí)候她會(huì)偷偷給你戴頂綠帽，這一切都是通過全局變量，特別在動(dòng)態(tài)鏈接的環(huán)境下，就算全部定義成強(qiáng)符號(hào)仍然無法為編譯器所察覺。而一些IT界“恐怖分子” 也經(jīng)常將惡意代碼包裝成全局變量注入到root權(quán)限下存在漏洞的操作序列中，就像著名的棧溢出攻擊那樣。某一天當(dāng)你傻傻地看著一個(gè)程序出現(xiàn)未定義的行為卻無法定位原因的時(shí)候，請(qǐng)不要忘記Richie大爺那來自九泉之下最深沉的“問候”~
或許有些人會(huì)偷換概念，把這一切歸咎于編譯器和鏈接器身上，認(rèn)為這同語言無關(guān)，但我要提醒你，正是編譯/鏈接器的行為支撐了整個(gè)語言的語法和語義。你可以反過來思考一下為何C的胞弟C++推出“命名空間(namespace)”的概念，或者你可以使用其它高級(jí)語言，對(duì)于重定義的全局變量是否能通過編譯這一關(guān)。
所以請(qǐng)時(shí)刻謹(jǐn)記，C是一門很恐怖的語言！
P.S.題外話寫在最后。我無意挑起語言之爭(zhēng)，只是就事論事地去“黑(hack)”一門語言而已，而且要黑就要黑得有理有力有層次，還要帶點(diǎn)娛樂精神。其實(shí)黑一門語言并非什么尖端復(fù)雜的技術(shù)，個(gè)人覺得起碼要做到兩點(diǎn)：
- 親自動(dòng)手寫測(cè)試程序。動(dòng)手寫測(cè)試程序是開發(fā)人員必備的基礎(chǔ)技能，只有現(xiàn)成的代碼才能讓人心服口服，那些只會(huì)停留在口頭上的爭(zhēng)論只能算作cheap hack。
- 測(cè)試程序不能依賴于不成熟的代碼。軟件開發(fā)99%以上的bug都是基于不合格(substandard)開發(fā) 人員導(dǎo)致，這并不能怪罪于語言以及編譯器本身。使用諸如#define TRUE FALSE或者#define NULL 1之類的trick來黑C語言只能證明此人很有娛樂精神而不是真正的”hack value”，拿老北京梨園行當(dāng)里的一句話——“那是下三濫的玩意兒”。
