C語言未定義行為經典案例：q = (++j) + (++j) + (++j) 為什麼結果不一致？

前言

面試經典題：int j = 7, q = (++j) + (++j) + (++j); 請問 `q` 與 `j` 的值？

許多初學者會直覺回答：`j` 變 10，`q = 8+9+10 = 27`。但在 C 標準下，這段代碼屬於未定義行為。不同編譯器、不同優化等級、甚至同編譯器不同版本，產生的結果可能完全不同。本文深入剖析根本原因、彙編層面差異、標準規定與避坑指南。

一、標準規定：序列點與副作用

• C99/C11 標準 (6.5 段落 2-3)：在兩個序列點之間，對同一標量物件的修改最多只能發生一次；且若修改發生，先前的值只能用於決定要儲存的值。
• 序列點：函數呼叫進入/返回、完整表達式結尾 (`;`)、`&&` `||` `?:` `,` (逗號運算子) 等運算子的求值點。
• (++j) + (++j) + (++j) 是單一完整表達式，**僅結尾有一個序列點**。其中對 `j` 有三次修改 (`++j` 三次)，且每次修改的值參與了加法運算 (非單純決定儲存值) → **嚴重違規 → 未定義行為 (UB)**。

二、編譯器實測差異 (x86-64, GCC/MSVC)

彙編層面解析 (GCC -O0 典型模式)

; 假設 j 在 [rbp-4]
mov  eax, DWORD PTR [rbp-4]  ; eax = j (7)
add  eax, 1                  ; eax = 8 (++j 第1次)
mov  DWORD PTR [rbp-4], eax  ; j = 8
mov  ecx, DWORD PTR [rbp-4]  ; ecx = j (8)
add  ecx, 1                  ; ecx = 9 (++j 第2次)
mov  DWORD PTR [rbp-4], ecx  ; j = 9
mov  edx, DWORD PTR [rbp-4]  ; edx = j (9)
add  edx, 1                  ; edx = 10 (++j 第3次)
mov  DWORD PTR [rbp-4], edx  ; j = 10
add  eax, ecx                ; eax = 8+9 = 17
add  eax, edx                ; eax = 17+10 = 27? 實際常因寄存器重用順序不同導致 22/24/30

關鍵點：編譯器**不保證**三個 `++j` 的求值順序，也不保證中間值是寫回記憶體還是停留在寄存器。優化器可能直接常數傳播、重排指令、甚至刪除看似無用的存取。

三、為什麼標準不規定順序？

1. 硬體多樣性：不同 CPU 指令集、暫存器數量、管線架構，固定求值順序會嚴重限制優化空間。
2. 優化自由度：編譯器可自由重排、合併、消除副作用操作，產生最快機器碼。
3. 歷史包袱：早期 C 編譯器各自為政，標準化時為兼容既有實現，選擇將此類表達式定為 UB。

四、相關未定義行為變體

i = i++ + ++i;        // UB: 多次修改 i
a[i] = i++;           // UB: 修改 i 並用於陣列索引
printf("%d %d", i++, i++); // UB: 引數求值順序未定 (但序列點在函數呼叫邊界)
i = (i, ++i, ++i);    // OK: 逗號運算子引入序列點，依序求值

五、避坑指南：如何正確寫出「連續自增並求和」？

明確意圖，分步寫，引入序列點：

// 寫法 1: 明確序列
int j = 7;
int q = 0;
q += ++j; // j=8, q=8
q += ++j; // j=9, q=17
q += ++j; // j=10, q=27

// 寫法 2: 使用逗號運算子 (單一表達式，但有序列點)
int j = 7, q;
q = (++j, ++j, ++j, j + (j-1) + (j-2)); // 晦澀，不推薦

// 寫法 3: 函數封裝 (最清晰)
int add_and_inc(int *p) { return ++(*p); }
int j = 7, q = add_and_inc(&j) + add_and_inc(&j) + add_and_inc(&j); // 明確順序

六、工具輔助檢測

• 編譯器警告：`gcc -Wall -Wextra -Wsequence-point` 可檢測部分 UB。
• 靜態分析：Cppcheck, Clang Static Analyzer, PVS-Studio。
• 動態檢測：AddressSanitizer (ASan) + UndefinedBehaviorSanitizer (UBSan)：

  gcc -fsanitize=undefined -g test.c -o test
  ./test
  // 輸出: runtime error: multiple unsequenced modifications to 'j'

七、總結

1. q = (++j) + (++j) + (++j) 是**教科書級未定義行為**，**絕不可用於生產代碼**。
2. 結果取決於編譯器實現細節 (寄存器分配、指令排程、優化策略)，**不可移植、不可預測**。
3. C 語言**不保證**運算元求值順序 (除 `&&` `||` `?:` `,` 外)，**副作用與值計算不可交織**。
4. 良好習慣：一條語句只做一件事，用序列點 (分號、逗號運算子、函數呼叫) 明確分隔副作用。
5. 開啟 `-Wall -Wextra -Wsequence-point` 並引入 UBSan 到 CI 流程，讓編譯器幫你守住底線。

理解 UB 不是為了「利用它」，而是為了徹底避開它。這正是 C 程式設計師從「能跑通」進化為「寫正確、可移植、可維護代碼」的關鍵認知躍升。