您现在的位置：程式碼之家 >> 編程語言 > >> C語言 >> C >> 關於C

淺析C語言函數返回局部變量地址的「似是而非」現象

編輯：關於C

很多 C 語言初學者都會犯一個經典錯誤：在函數中返回棧上局部變量的地址。教科書上明確說這是未定義行為（UB），但在實際運行中，程序往往能「正常」輸出預期結果，甚至連續多次調用返回相同地址。這究竟是編譯器寬容，還是記憶體佈局的必然規律？本文通過實驗現象剖析底層原理，揭開這層迷霧。

現象重現：為什麼它「能跑通」？

考慮如下代碼：

int* sum(int x, int y) {
    int a = x + y;
    return &a; // 返回局部變量地址
}

int main() {
    int *p = sum(10, 2);
    printf("*p=%d, p=%p\\n", *p, p); // 輸出 12 和某地址
    *p = 100; // 甚至能修改成功！
    printf("*p=%d\\n", *p); // 輸出 100
}

在許多編譯器（如 MSVC、GCC 未開啟優化）下，這段代碼不僅編譯通過，運行結果還看似正確。更有趣的是，連續兩次調用 sum(10,2) 返回的地址竟然完全相同！

本質解析：棧幀的「重用」機制

這並非編譯器「幫你修好 Bug」，而是調用約定與棧佈局決定的必然結果：

棧幀固定偏移：同一函數在相同調用點被調用時，其棧幀在棧上的相對位置是固定的。局部變量 a 相對於幀指針（rbp/ebp）的偏移量在編譯期確定。
調用鏈一致性：main 兩次調用 sum 時，調用鏈完全相同，棧指針 rsp 指向位置相同，導致 sum 的棧幀落在同一記憶體區域。
內容未被覆蓋：sum 返回後，其棧幀雖邏輯上失效，但物理內存數據暫時保留，直到被後續函數調用覆蓋。

因此，main 拿到的地址恰好指向剛被釋放的棧空間，數據尚未被破壞，讀寫看似正常。但這屬於「懸空指針」，屬於未定義行為，隨時可能因中斷、信號處理、編譯器優化或後續函數調用而崩潰。

實驗驗證：插入干擾函數即露餡

在兩次 sum 調用之間插入任意函數調用（如 getsum()），哪怕該函數不使用相同棧空間，也會改變棧指針位置，導致第二次 sum 的棧幀偏移，返回地址發生變化，且第一次返回的指針指向的內容被覆蓋：

int *p = sum(10, 2);       // 第一次調用
printf("*p=%d\\n", *p);     // 12
getsum(1, 2);              // 干擾棧
p = sum(10, 2);            // 第二次調用，地址可能不同
printf("*p=%d\\n", *p);     // 仍為 12，但第一個 p 指向的內容已不可靠

若在中間調用 free() 或進行大量棧操作，程序更會直接因堆棧破壞而崩潰（如實驗截圖所示的 heap/stack corruption）。