我們知道，全局變量是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。

第一個(gè)例子

#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è)例子。

第二個(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？

第三個(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在九泉之下邪惡的笑聲——不，與其說是嘲笑，不如說是詛咒……

第四個(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è)似乎沒有影響。

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)。

到此這篇關(guān)于四個(gè)例子說明C語言 全局變量的文章就介紹到這了,更多相關(guān)C全局變量多多內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后支持腳本之家！

最新評(píng)論