1. 程式人生 > >C語言變長陣列之剖析

C語言變長陣列之剖析

C語言變長陣列之剖析

(陳雲川 [email protected] UESTC,CD)

1、引言

我們知道,與C++等現代程式語言不同,傳統上的C語言是不支援變長陣列功能的,也就是說陣列的長度是在編譯期就確定下來的,不能在執行期改變。不過,在C99標準中,新增的一項功能就是允許在C語言中使用變長陣列。然而,C99定義的這種變長陣列的使用是有限制的,不能像在C++等語言中一樣自由使用。

2、說明

參考文獻[1]中對變長陣列的說明如下:

C99 gives C programmers the ability to use variable length arrays, which are arrays whose sizes are not known until run time. A variable length array declaration is like a fixed array declaration except that the array size is specified by a non-constant expression. When the declaration is encountered, the size expression is evaluated and the array is created with the indicated length, which must be a positive integer. Once created, variable length array cannot change in length. Elements in the array can be accessed up to the allocated length; accessing elements beyond that length results in undefined behavior. There is no check required for such out-of-range accesses. The array is destroyed when the block containing the declaration completes. Each time the block is started, a new array is allocated.

以上就是對變長陣列的說明,此外,在文獻[1]中作者還說明,變長陣列有以下限制:

1、變長陣列必須在程式塊的範圍內定義,不能在檔案範圍內定義變長陣列;

2、變長陣列不能用static或者extern修飾;

3、變長陣列不能作為結構體或者聯合的成員,只能以獨立的陣列形式存在;

4、變長陣列的作用域為塊的範圍,對應地,變長陣列的生存時間為當函式執行流退出變長陣列所在塊的時候;

上述限制是最常見的一些限制因素,此外,當通過typedef定義變長陣列型別時,如何確定變長陣列的長度,以及當變長陣列作為函式引數時如何處理,作者也做了一一說明。詳細的細節情況請參閱文獻[1]。由於變長陣列的長度在程式編譯時未知,因此變長陣列的記憶體空間實際上是在棧中分配的。

gcc雖然被認為是最遵守C語言標準的編譯器之一,但是它並不是嚴格按照ISO C標準規定的方式來實現的。gcc的實現方式採取了這樣的策略:最大限度地遵守標準的規定,同時從實用的角度做自己的擴充套件。當然,gcc提供了編譯選項給使用者以決定是否使用這些擴充套件功能。gcc的功能擴充套件分為兩種,一種是gnu自己定義的語言擴充套件;另外一種擴充套件是在C89模式中引入由C99標準定義的C語言特性。在參考文獻[2]中,有關gcc的C語言擴充套件佔據了將近120頁的篇幅,擴充套件的語言功能多達幾十個,由此可看出gcc的靈活程度。

在參考文獻[2]中,對變長陣列的描述如下:

Variable-length automatic arrays are allowed in ISO C99, and as an extension GCC accepts them in C89 mode and in C++. (However, GCC’s implementation of variable-length arrays does not yet conform in detail to the ISO C99 standard.) These arrays are declared like any other automatic arrays, but with a length that is not a constant expression. The storage is allocated at the point of declaration and deallocated when the brace-level is exited.

以上這段話並沒有詳細的說明gcc的變長陣列實現和ISO C99的差異究竟體現在什麼地方,但是從描述來看,基本上和文獻[1]中的描述是一致的。文獻[2]中沒有說明而在文獻[1]中給予了說明的幾點是:變長陣列是否能用static或者extern修飾;能否作為複合型別的成員;能否在檔案域起作用。

另外,在文獻[2]中提到,採用alloca()函式可以獲得和變長陣列相同的效果。在作者所用的Red Hat 9.0(Linux 2.4.20-8)上,這個函式被定義為一個庫函式:

#include <alloca.h>

void *alloca(size_t size);

這個函式在呼叫它的函式的棧空間中分配一個size位元組大小的空間,當呼叫alloca()的函式返回或退出的時候,alloca()在棧中分配的空間被自動釋放。當alloca()函式執行成功時,它將返回一個指向所分配的棧空間的起始地址的指標;然而,非常特別的一點是,當alloca()函式執行失敗時,它不會像常見的庫函式那樣返回一個NULL指標,之所以會出現這樣的狀況,是由於alloca()函式中的棧調整通常是通過一條彙編指令來完成的,而這樣一條彙編指令是無法判斷是否發生溢位或者是否分配失敗的。alloca()函式通常被實現為行內函數,因此它是與特定機器以及特定編譯器相關聯的,可移植性因此而大打折扣,實際上是不推薦使用的。

作者之所以會關注變長陣列的問題是出於一次偶然的因素,在除錯的時候發現gdb給出的變長陣列的型別很怪異,由此引發作者對gcc中的變長陣列進行了測試。本文中給出的就是對測試結果的說明和分析。

3、例項

第一個測試所用的原始碼很簡單,如下所示:

 1 int

 2 main(int argc, char *argv[])

 3 {

 4 int i, n;

 5

 6 n = atoi(argv[1]);

 7 char arr[n+1];

 8 bzero(arr, (n+1) * sizeof(char));

 9 for (i = 0; i < n; i++) {

10      arr[i] = (char)('A' + i);

11 }

12 arr[n] = '\0';

13 printf("%s\n", arr);

14

15 return (0);

16 }

上述程式名為dynarray.c,其工作是把引數argv[1]的值n加上1作為變長陣列arr的長度,變長陣列arr的型別為char。然後向陣列中寫入一些字元,並將寫入的字串輸出。

像下面這樣編譯這個程式:

[root@cyc test]# gcc -g -o dynarray dynarray.c

然後,用gdb觀察dynarray的執行情況:

[root@cyc test]# gdb dynarray

(gdb) break main

Breakpoint 1 at 0x80483a3: file dynarray.c, line 6.

(gdb) set args 6

(gdb) run

Starting program: /root/source/test/a.out 6

 

Breakpoint 1, main (argc=2, argv=0xbfffe224) at dynarray.c:6

6               n = atoi(argv[1]);

(gdb) next

7               char arr[n+1];

(gdb) next

8               bzero(arr, (n+1) * sizeof(char));

(gdb) print/x arr

$2 = {0xb0, 0xe5}

(gdb) ptype arr

type = char [2]

(gdb) print &arr

$3 = (char (*)[2]) 0xbfffe1c8

這裡,當程式執行流通過了為變長陣列分配空間的第7行之後,用print/x命令打印出arr的值,結果居然是兩個位元組;而如果嘗試用ptype打印出arr的型別,得到的結果居然是arr是一個長度為2的字元陣列。很明顯,在本例中,因為提供給main()函式的引數argv[1]是6,因此按常理可知arr應該是一個長度為7的字元陣列,但很遺憾,gdb給出的卻並不是這樣的結果。用print &arr打印出arr的地址為0xbfffe1c8。繼續上面的除錯過程:

(gdb) x/4x &arr

0xbfffe5c8:     0xbfffe5b0      0xbfffe5c0      0x00000006      0x40015360

(gdb) x/8x $esp

0xbfffe5b0:     0xbffffad8      0x42130a14      0xbfffe5c8      0x0804828d

0xbfffe5c0:     0x42130a14      0x4000c660      0xbfffe5b0      0xbfffe5c0

可以看到,在&arr(即地址0xbfffe5c8)處的第一個32位值是0xbfffe5b0,而通過x/8x $esp可以發現,棧頂指標esp恰好就指向的是0xbfffe5b0這個位置。於是,可以猜想,如果arr是一個指標的話,那麼它指向的就恰好是當前棧頂的指標。繼續上面的除錯:

(gdb) next

9               for (i = 0; i < n; i++) {

(gdb) next

10                      arr[i] = (char)('A' + i);

(gdb) next

9               for (i = 0; i < n; i++) {

(gdb) until

12              arr[n] = '\0';

(gdb) next

13              printf("%s\n", arr);

(gdb) x/8x $esp

0xbfffe5b0:     0x44434241      0x42004645      0xbfffe5c8      0x0804828d

0xbfffe5c0:     0x42130a14      0x4000c660      0xbfffe5b0      0xbfffe5c0

注意上面表示為藍色的部分,由於Intel平臺採用的是小端位元組序,因此藍色的部分實際上就是’ABCDEF’的十六進位制表示。而紅色的32位字則暗示著arr就是指向棧頂的指標。為了確認我們的這一想法,下面通過修改arr的值來觀察程式的執行情況(需要注意的是:每一次執行時堆疊的地址是變化的):

(gdb) run

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /root/source/test/dynarray 6

 

Breakpoint 1, main (argc=2, argv=0xbfffde24) at dynarray.c:6

6               n = atoi(argv[1]);

(gdb) next

7               char arr[n+1];

(gdb) next

8                                                     bzero(arr, (n+1) * sizeof(char));

(gdb) print/x &arr

$3 = 0xbfffddc8

(gdb) x/8x $esp

0xbfffddb0:     0xbffffad8      0x42130a14      0xbfffddc8      0x0804828d

0xbfffddc0:     0x42130a14      0x4000c660      0xbfffddb0      0xbfffddc0

(gdb) set *(unsigned int*)&arr=0xbfffddc0

(gdb) x/8x $esp

0xbfffddb0:     0xbffffad8      0x42130a14      0xbfffddc8      0x0804828d

0xbfffddc0:     0x42130a14      0x4000c660      0xbfffddc0      0xbfffddc0

(gdb) next

9               for (i = 0; i < n; i++) {

(gdb) next

10                      arr[i] = (char)('A' + i);

(gdb) next

9               for (i = 0; i < n; i++) {

(gdb) until

12              arr[n] = '\0';

(gdb) next

13              printf("%s\n", arr);

(gdb) x/8x $esp

0xbfffddb0:     0xbffffad8      0x42130a14      0xbfffddc8      0x0804828d

0xbfffddc0:     0x44434241      0x40004645      0xbfffddc0      0xbfffddc0

地址0xbfffddc8(也就是arr的地址)處的值本來為0xbfffddb0,我們把它改成了0xbfffddc0,於是,當程式執行到向變長陣列輸入資料完成之後,我們發現這次修改的地址的確是從0xbfffddc0開始的。這就表明arr的確像我們通常所理解的一樣,陣列名即指標。只不過這個指標指向的位置在它的下方(堆疊向下生長),而不是像大多數時候一樣指向上方的某個位置。

4、分析

上面的測試結果表明:變長陣列的確是在棧空間中分配的;變長陣列的陣列名實際上就是一個地址指標,指向陣列所在的棧頂位置;而GDB無法判斷出變長陣列的陣列名實際上是一個地址指標。

GDB為什麼無法準確判斷出變長陣列的型別的原因尚不清楚,但是作者猜測這和變長陣列的動態特性有關,由於變長陣列是在程式動態執行的過程生成的,GDB無法向對待常規陣列一樣從目標檔案包含的.stabs節中獲得長度資訊,於是給出了錯誤的型別資訊。

另外,作者對變長陣列的作用域進行了測試,測試程式碼根據上例修改得到,如下所示:

 1 int n;

 2 char arr[n+1];

 3

 4 int

 5 main(int argc, char *argv[])

 6 {

 7      int i;

 8

 9      n = atoi(argv[1]);

10      bzero(arr, (n+1) * sizeof(char));

11      for (i = 0; i < n; i++) {

12              arr[i] = (char)('A' + i);

13      }

14      arr[n] = '\0';

15      printf("%s\n", arr);

16

17      return (0);

18 }

當如下編譯的時候,gcc會提示出錯:

[root@cyc test]# gcc -g dynarray.c

dynarray.c:2: variable-size type declared outside of any function

可見gcc不允許在檔案域定義變長陣列。

對於gcc中的變長陣列能否用static修飾則使用如下程式碼進行測試:

 1 int

 2 main(int argc, char *argv[])

 3 {

 4      int i, n;

 5

 6      n = atoi(argv[1]);

 7      static char arr[n+1];

 8      bzero(arr, (n+1) * sizeof(char));

 9      for (i = 0; i < n; i++) {

10              arr[i] = (char)('A' + i);

11      }

12      arr[n] = '\0';

13      printf("%s\n", arr);

14

15      return (0);

16 }

當編譯此原始檔的時候,gcc給出如下錯誤提示:

[[email protected] test]# gcc -g dynarray.c

dynarray.c: In function `main':

dynarray.c:7: storage size of `arr' isn't constant

dynarray.c:7: size of variable `arr' is too large

根據提示,可知當陣列用static修飾的時候,不能將其宣告為變長陣列。至於這裡的提示說arr太大,作者猜測可能的原因是這樣的:對於整數,gcc在編譯期賦予了一個非常大的值,於是導致編譯報錯,不過這僅僅是猜測而已。

最後需要說明的是,作者是出於對gcc如何實現變長陣列的方式感興趣才進行上面的這些測試的。對於程式設計者來說,不用做這樣的測試,也不需要知道變長陣列是位於棧中還是其它地方,只要知道變長陣列有上面這樣一些限制就行了。另外,本文中有很多地方充斥著作者的推斷和猜測。不過這並沒有太大的關係,又不是寫論文,誰在乎呢?

另外,上面的測試也說明了:儘管文獻[2]沒有像文獻[1]中那樣仔細說明變長陣列的限制條件,但實際上它就是那樣工作的。再一次體現出gcc的確很好地遵守了C標準的規定。

參考文獻

[1] Samuel P. Harbison III, Guy L. Steele Jr.; C: A Reference Manual Fifth Edition; Prentice Hall, Pearson Education, Inc.; 2002

[2] Richard M. Stallman and the GCC Developer Community; Using the GNU Compiler Collection; FSF; May 2004