背景

這篇文章源於一位開發者在現代編譯環境下重新編譯 30 年前的《毀滅戰士》（Doom）原始碼時，遇到了一個極其詭異的臭蟲：一個布林變數竟然同時既是 true 又是 false。作者透過 Godbolt 編譯器探索工具深入研究 x86 組合語言，最終發現問題出在 C99 標準引入的 _Bool 型別與舊時代程式碼中使用 memset 將結構初始化為 -1 的行為產生了衝突，導致了未定義行為（Undefined Behavior, UB）。

社群觀點

針對作者的除錯歷程，Hacker News 社群展開了激烈的技術辯論。部分留言者認為作者繞道研究組合語言雖然有趣，但在實務上效率極低。他們指出，現代 C 語言開發應優先使用 Undefined Behavior Sanitizer (UBSAN) 等工具，這類工具能直接指出違反標準的具體位置，省去猜測組合語言邏輯的時間。然而，反對者則認為，僅僅「修復」問題是不夠的，深入底層去理解編譯器如何利用布林值的嚴格定義（僅限 0 或 1）來進行優化，才是提升程式設計直覺的關鍵。這種對底層機制的探索，能讓人理解為何編譯器會將 == false 轉譯為 != 1，進而導致非 0 且非 1 的數值在邏輯判斷中失效。

關於程式碼風格的爭論也隨之而起。許多資深開發者批評在條件式中使用 if (x == true) 或 if (x == false) 是不良習慣，認為這反映了開發者對布林表達式的本質理解不足。他們主張應直接使用 if (x) 或 if (!x)，因為在 C 語言的傳統中，零為假、非零即為真，這種寫法能有效規避 _Bool 型別帶來的陷阱。但也有人反駁，當 _Bool 被引入標準後，它不再只是整數的別名，而是一個具有特定有效位元模式的型別，任何透過 memset 或指標強轉入非法數值的行為，本質上就是在破壞型別系統。

此外，社群也探討了軟體維護的哲學問題。有觀點認為，面對 30 年前的老舊代碼，最理性的做法是將編譯標準鎖定在 C89 或 C17 以前，而不是強行用現代標準去檢視。這引發了對不同語言處理版本相容性的討論，例如 Rust 的「Edition」機制或 Go 的版本標記，都被視為比 C 語言依賴 Makefile 參數更優雅的解決方案。甚至有激進的觀點建議，為了徹底避免這類環境差異導致的崩潰，開發者應該考慮將特定版本的編譯器直接包含在專案倉庫中，以確保構建結果的絕對一致性。

最後，關於布林值的數學與硬體表示法也引起了小規模討論。雖然現代電腦科學慣用 0 代表假、1 代表真，但留言者提到在某些古老的系統或語言（如 QBasic 或某些 Fortran 編譯器）中，真值被定義為 -1（即所有位元皆為 1）。這種歷史背景解釋了為何舊時代的程式設計師會習慣使用 memset 填滿 -1 來初始化資料，卻沒料到這種做法會在數十年後與追求極致優化的現代編譯器產生致命衝突。

延伸閱讀

在討論中，參與者提到了幾個有助於理解與預防此類問題的資源與工具：

• Godbolt Compiler Explorer：文中作者用來觀察不同編譯器優化行為的核心工具。
• -fsanitize=undefined (UBSAN)：留言者強烈建議優先使用的執行期檢測工具，可捕捉布林值溢出等未定義行為。
• Guix 與 Nix：被提及作為管理開發環境與編譯器版本一致性的現代解決方案。
• Rust Editions：作為對比，討論了 Rust 如何透過 crate 層級的版本宣告來處理語言標準的演進。