Fil-C：垃圾進，記憶體安全出［影片］ （★ 76 分）
這場由 Filip Pizlo 在 Software Should Work 2026 發表的演講，主張 C 與 C++ 的記憶體安全問題不必然只能靠改寫成其他語言解決。傳統 C/C++ 中，一處簡單錯誤可能在既有的複雜緩解措施下，仍被利用來達成遠端程式碼執行（remote code execution, RCE）。Fil-C 提供一套 C/C++ 編譯器與執行期環境，試圖讓這些語言達到與最安全語言相當的記憶體安全防護；演講也介紹其編譯器、執行期，以及已移植的軟體。原始影片頁面回傳 403 Forbidden，未提供完整逐字稿，因此可確認的內容主要來自影片摘要與討論中的技術說明。
HN 討論指出，Fil-C 與 Rust 的核心差異，在於前者主要依靠執行期檢查，後者則傾向在編譯期避免未定義行為（undefined behavior，程式執行結果不受語言規範保證）。Fil-C 將安全邊界集中在編譯器、執行期、垃圾回收器（garbage collector, GC）與自訂 C 標準函式庫，應用程式及其相依元件不能自行撰寫 unsafe 區塊。Pizlo 進一步說明，Fil-C 的使用者端函式庫會把系統呼叫（system call，應用程式向作業系統核心要求服務的介面）交給 Fil-C 執行期過濾，讓安全檢查延伸到系統呼叫層；這也是他認為 Fil-C 比含有 unsafe 程式碼的 Rust 更全面之處。部分討論者則認為，這種執行期防護也可能作為 Rust 的補強工具，而不必被視為 Rust 的替代品。
爭議主要集中在「比 Rust 更安全」這項說法的適用範圍。支持 Fil-C 的觀點認為，Rust 的安全子集仍可經由 unsafe 程式碼或低階系統呼叫破壞記憶體安全，而 Fil-C 不讓應用程式或相依元件自行越過這道界線；以 mmap（記憶體映射系統呼叫）為例，Fil-C 提供自己的安全包裝介面，Rust 的安全子集則難以涵蓋所有共享映射情境。反方則指出，Rust 同樣能使用安全包裝函式庫，也能禁止整個專案採用 unsafe；此外，並非所有系統呼叫都能完整包裝。討論者也提醒，Rust 的一般陣列索引通常仍會在執行期檢查，但迭代器、型別系統及其他形式的證明可以消除部分檢查，帶相依型別的語言和 WUFFS 等工具則能進一步進行靜態證明。
效能與實際部署仍是 Fil-C 的主要待驗證部分。批評者擔心執行期檢查、垃圾回收與額外分支會造成明顯負擔，導致正式環境仍得以一般 C 編譯器編譯；也有人認為 Fil-C 的速度已足以應付部分正式工作負載，且相較於 AddressSanitizer（ASan，用來偵測記憶體錯誤的編譯器檢查工具）和 Valgrind（以動態分析追蹤程式錯誤的工具），它的目標是提供可長期啟用的安全保護，而不只是測試工具。整體而言，HN 討論肯定 Fil-C 能以相對少的程式碼修改，為既有 C/C++ 程式帶來記憶體安全；但也認為它目前以 Linux 為主，系統核心、硬體錯誤、資料競爭與特殊的程序介面仍可能落在保護範圍之外，因此「記憶體安全」不應被宣稱為完整的系統安全保證。
👥 60 則討論、評論 💬
https://news.ycombinator.com/item?id=49026933