C語言整型溢出為何不報錯？int 類型寬度與編譯器實現差異解析

現象重現

#include <stdio.h>
void main() {
    int a = 32767;  // 16位有符號int最大值
    int b = a + 2;  // 32769，超出16位範圍
    printf("%d, %d\n", a, b);
}

**輸出**：`32767, 32769`（正常顯示，無錯誤、無截斷）。
**預期（16位int）**：溢出導致未定義行為，可能輸出 `-32767` 或崩潰。

核心原因：現代編譯器 int 默認 32 位（4 字節）

**結論**：代碼運行在 **32/64 位現代編譯器** 下，int 寬度為 32 位，範圍 ±21 億，**32769 遠未溢出**，故正常輸出。這不是「軟件出錯」，而是**硬件架構升級、編譯器實現跟進**的結果。

C 標準對 int 寬度的規定

• 最小 16 位（C90/C99/C11/C17/C23 均要求 INT_MAX ≥ +32767，即至少 16 位）。
• 無上限限制：實現可選 16/32/64 位，甚至 24/36 位（歷史機型）。
• 建議：「足夠容納目標機器字長」，現代桌面/服務器/移動端普遍 32 位。

如何編寫可移植、無溢出風險的代碼？

1. 使用精確寬度類型 (<stdint.h>，C99)

#include <stdint.h>
int16_t a = 32767;   // 確切 16 位有符號
int32_t b = a + 2;   // 確切 32 位，無溢出
// 或
int_least16_t c = 32767; // 至少 16 位（通常即 int16_t）

2. 靜態斷言檢查範圍 (C11 _Static_assert)

_Static_assert(INT_MAX >= 100000, "int太窄，需至少17位");

3. 運行時檢查溢出（有符號溢出是 UB，需預判）

#include <limits.h>
if (a > 0 && b > INT_MAX - a) { /* 加法會溢出 */ }
if (a < 0 && b < INT_MIN - a) { /* 加法會溢出 */ }

4. 使用無符號類型或更寬類型承接結果

long long sum = (long long)a + b; // 強制提升寬度
unsigned int u = a + 2u; // 無符號溢出定義為模 2^n 環繞，行為明確

為什麼 C 不在運行時檢查溢出？

• 性能優先：檢查每條算術指令會嚴重拖慢速度，違背 C「接近硬件、零開銷」設計哲學。
• 硬件差異：不同 CPU 對溢出標誌位處理不同，統一運行時檢查極難。
• 未定義行為 (UB) 留給編譯器優化空間：假設無溢出，編譯器可大膽優化（如循環變量推導、常量折疊）。

調試溢出的利器

• 編譯器衛生檢查器：GCC/Clang -fsanitize=signed-integer-overflow -fsanitize=undefined（UBSan），運行時捕獲有符號溢出並報告。
• 靜態分析：Cppcheck、Clang Static Analyzer、Coverity 可發現潛在溢出路徑。
• 單元測試邊界值：構造 INT_MAX、INT_MIN 等極值輸入跑測試。

總結

現代桌面/移動端編譯器 int 普遍為 **32 位**，範圍 ±21 億，故 32767+2 **不溢出**、正常輸出。這反映了**計算機架構從 16 位向 32/64 位演進**，而非軟件故障。
編寫健壯代碼應：用 <stdint.h> 精確類型、靜態斷言範圍、開啟 UBSan 檢測、避免依賴 int 寬度假設。理解「類型寬度由實現定義、標準只定下限」是寫可移植 C 代碼的關鍵認知。

1. 上一篇文章： C語言遞歸實現楊輝三角（帕斯卡三角形）完整代碼與原理
2. 下一篇文章： C語言基礎選擇題詳解：逗號運算符、typeof、轉義字符、ASCII碼

C 語言問答

C語言鏈表學生信息系統：結構體定義缺分號導致編譯錯誤

錯誤代碼定位 struct student { in

C語言二維數組完整操作指南：輸入、輸出、傳參與內存佈局

二維數組：從定義到高級用法全解析 定義與初始化 int a

C 語言輸入輸出型別轉換導致輸出值不同：int vs char 格式指示符差異

現象重現 使用者發現同一變數用 %d (有號十進制整數) 與

C語言排序算法對決：冒泡排序 vs 選擇排序，誰效率更高？

結論先行 **總體而言，選擇排序效率略高於冒泡排序**（或持