Lib0xc：一組用於增強系統程式設計安全性的 C 標準函式庫擴充介面

背景

微軟近期開源了名為 lib0xc 的 C 語言標準庫擴展，旨在為系統程式設計提供更安全的 API 替代方案。雖然 C 語言本身無法在語言層級完全實現類型與邊界安全，但 lib0xc 透過封裝常見的 GNUC 擴展與 C11 特性，試圖將業界流傳已久的「安全實踐」轉化為具備完整文檔與測試的正式介面，藉此降低緩衝區溢位或整數轉換錯誤等常見風險。

社群觀點

Hacker News 社群對此專案展現了高度興趣，多數開發者認為這類針對 C 語言「低垂果實」的安全性改進早該普及。支持者指出，空間記憶體安全問題有九成可以透過強制使用安全介面來解決，甚至有開發者認為，若將此類庫與 C++ 的安全子集結合，其競爭力足以挑戰 Zig 等新興語言。然而，社群也對標準化進程緩慢感到無奈，有觀點批評 C 與 C++ 標準委員會長期拒絕承認問題，或將安全責任推給開發者，導致這些本應由標準庫提供的功能，至今仍需依賴第三方庫或編譯器擴展。

專案作者 EPWN3D 親自參與了討論，澄清了 lib0xc 的設計初衷與應用場景。他強調這並非要取代 Rust 或 Zig，而是為了讓現有的 C 代碼庫能以「漸進式」的方式提升安全性。例如，開發者可以將 sprintf 替換為 ssprintf，或利用 __cast_signed_unsigned 來處理整數轉換，從而開啟更嚴格的編譯器警告（如 -Wint-conversion）而不必擔心運行時的未定義行為。作者坦言，雖然現代語言如 Zig 擁有強大的編譯期求值能力，但 lib0xc 的目標是透過 Clang 的邊界安全擴展（-fbounds-safety），在不改變 C 語言本質的前提下，盡可能擴大開發者的「成功之坑」（Pit of Success）。

討論中也出現了一些技術性的質疑與擔憂。有使用者詢問該庫是否能在生產環境運行，作者表示這目前是 Azure 內部某專案的一部分，未來將持續維護。另外，有開發者提醒 lib0xc 的命名與現有的量子化學庫 libxc 過於接近，可能造成混淆。關於 C 語言如何達到現代語言的使用體驗，作者認為標準委員會應更積極地減少對堆積記憶體（Heap）與 void * 指標的依賴，並將邊界安全註解納入一等語言特性。整體而言，社群共識傾向於認可這種「標準庫鄰接」的改進路徑，認為這是在無法立即遷移到新語言的現實下，保護既有基礎設施的務實手段。

延伸閱讀

• Clang bounds-safety extensions：lib0xc 深度整合的編譯器安全特性。
• sys/unit.h 與 sys/check.h：lib0xc 內建的單元測試與斷言介面。
• libxc：名稱相近但功能完全不同的量子化學庫，讀者需注意區分。