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] = '';
13 printf("%sn", 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] = '';
(gdb) next
13 printf("%sn", 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] = '';
(gdb) next
13 printf("%sn", 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] = '';
15 printf("%sn", 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] = '';
13 printf("%sn", arr);
14
15 return (0);
16 }
當編譯此源文件的時候，gcc給出如下錯誤提示：
[root@cyc 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
