每位編譯器撰寫者都該了解的程式設計師知識

背景

這篇 2015 年的經典文章探討了編譯器開發者與一般程式設計師之間對於「未定義行為」（Undefined Behavior, UB）認知上的巨大鴻溝。文章指出，編譯器作者傾向於利用標準中的模糊地帶進行極致優化，而程式設計師則往往依賴於對底層硬體的直覺理解，這種預期落差常導致難以調試的安全漏洞與邏輯錯誤。

社群觀點

Hacker News 的討論核心圍繞在 C 語言標準的詮釋權之爭。許多開發者對現代編譯器的行為感到憤怒，認為編譯器作者「綁架」了未定義行為的原意。在早期的 K&R 時代，UB 通常意味著「標準不保證結果，交由硬體決定」，例如解引用空指標就該發生頁面錯誤。然而，現代編譯器如 GCC 或 LLVM 則將其視為一種「不可能發生的假設」，並據此刪除後續的邏輯檢查。反對者認為這種「時間旅行式」的優化極其危險，例如整數溢位檢查被編譯器判定為不可能發生而遭移除，直接導致了安全防禦失效。

然而，另一派觀點則站在編譯器作者的立場，認為這種批評近乎「主權公民」式的無理取鬧。他們主張 C 語言並非直接操作裸機，而是針對「抽象機器」進行編程，編譯器只是忠實執行標準賦予的優化權力。若不允許編譯器假設 UB 不會發生，許多關鍵優化（如別名分析、循環展開）將難以實施，導致程式執行效率大幅下降。支持者強調，程式設計師不能既想要現代編譯器帶來的效能紅利，又拒絕承擔遵循標準規範的責任。

討論中也觸及了實務上的困境。有開發者指出，在大型遺留系統中完全消除 UB 幾乎是不可能的任務，即使是像 Linux 核心這樣的高度專業專案，也難以完全避免。這引發了關於「友善 C 語言方言」的討論，有人提議應該存在一種更具預測性的編譯模式，讓舊程式碼能安全運行。但反駁者認為，技術債終究需要償還，若開發者不願使用靜態分析工具或開啟警告標籤，卻反過來指責編譯器太過聰明，這在邏輯上是自相矛盾的。

最後，社群對於 C 語言的未來展現出分歧。一部分人認為 C 語言的複雜性與陷阱已使其不再適合現代開發，轉而推薦 Rust 或 Zig 等更安全的替代方案。但資深開發者如 Walter Bright 則提醒，語言的成功往往取決於生態系與工具鏈的成熟度，而非單純的語義定義。儘管爭議不斷，C 語言作為基礎建設的地位短期內仍難以撼動，這場關於編譯器與開發者之間信任關係的辯論，恐怕還會持續下去。

延伸閱讀

• Undefined Behavior in C is a Reading Error：Victor Yodaiken 對 C 標準中關於 UB 定義的法律式解讀與批判。
• The Most Subtle Bug：一個關於編譯器優化如何讓調試變得極其困難的真實案例。
• Friendly C：John Regehr 探討建立一個對開發者更友善、減少驚訝感的 C 語言方言的可能性。
• Fil-C：一個致力於實現完全記憶體安全的 C 語言編譯器專案。