劇透：數(shù)組名不是指針變量，僅在特定的用法上等同于指針；數(shù)組名是地址常量，因此無法更改自身所表示的地址（但并非指針常量）；對數(shù)組名取址在C語言標(biāo)準(zhǔn)中屬于未定義行為，具體取決于編譯器的實現(xiàn)，通常對數(shù)組名取址的表現(xiàn)與數(shù)組指針等同（仔細(xì)想想如何給一個數(shù)組指針賦值）。

來看一小段代碼片段引出本文的話題，作用是讀取文件內(nèi)容，在向read庫函數(shù)傳入第二項void *__buf參數(shù)時意外使用了數(shù)組名取址，正確的傳參形式同注釋部分，但最終都能正常讀取文件內(nèi)容：

如此看來，數(shù)組名與對數(shù)組名取址的結(jié)果似乎可以畫上等號？就像函數(shù)名與函數(shù)名取址那般。如果說數(shù)組對應(yīng)的是數(shù)組的首地址，那么對數(shù)組名取址自然是對首地址取址，結(jié)果至少也得是個二級地址（初學(xué)者的正常想法），如果把它作為緩沖內(nèi)存地址傳參那不得亂套？但就是莫名其妙地能跑??。

那就先從read庫函數(shù)的聲明入手，描述如下：

基本可以排除語法問題，void *類型說它收到的確實是指針類型，是個指針都行，沒毛??；C/C++編譯器說事到如今都聽你的，用戶永遠(yuǎn)都是對的；我。。。

快速分析一下問題的切入點一定是數(shù)組名和數(shù)組名取址所表達(dá)的含義，以及經(jīng)歷相同運(yùn)算后的結(jié)果含義，測試代碼如下：

測試結(jié)果如下：

從結(jié)果中可以看到數(shù)組名（array）、對數(shù)組名取址后的內(nèi)容（&array）均可以表示數(shù)組首個元素的地址，即數(shù)組首地址，這也就可以解釋向read庫函數(shù)中傳入取數(shù)組名地址后的結(jié)果作為參數(shù)，程序依舊能如期完成任務(wù)，最終的void *類型指針總能找到正確的緩沖區(qū)地址。

別急，數(shù)組名和對數(shù)組名取地址結(jié)果并非在任何場景下都能畫上等號，相反他們倆是完全不同的概念。取兩者的下一處地址進(jìn)行比較，同時加入一個等價的數(shù)組指針作比較，可以發(fā)現(xiàn)數(shù)組名的計算步長與數(shù)組元素大小一致，數(shù)組名取址的運(yùn)算步長與數(shù)組整體大小一致，與等價的數(shù)組指針的步長一致。因此對數(shù)組名取址的結(jié)果等價于數(shù)組指針。另外從元素的類型大小可以得出，數(shù)組名表現(xiàn)地更像是一種數(shù)據(jù)結(jié)構(gòu)類型，數(shù)組名取址則更加接近于普通的指針。

盡管C語言標(biāo)準(zhǔn)未給出對數(shù)組名取址的具體行為定義，但現(xiàn)代編譯器普遍認(rèn)為對數(shù)組取址的結(jié)果是數(shù)組指針的右值，從以下這條語句就可以看出。只不過在最初案例中傳參的時候因為某種疏忽或理解偏差而錯誤使用，但最終還是陰差陽錯地跑起來了。雖然結(jié)果正確，但軟件中的錯誤就是這么日積月累起來的。

明明是很簡單的概念理解偏差問題，但雜糅在一起就被唬住了，一時半會兒也轉(zhuǎn)不過彎，往往在很久之后的某一瞬間才猛然醒悟，時間和精力就是這么從我們手上悄悄溜走的。