djb 的 Fil-C 实用笔记:内存安全 C 编译器的真实代价
来源:cr.yp.to — 2025-2026
📋 概述
djb 记录了他用 Fil-C(filcc / fil++ 这对内存安全的 C/C++ 编译器)的经验,动机很实际:把他管的一批机器切到 Fil-C 编译的代码上。第一句评价是兼容性令人印象深刻——试过的库与应用几乎都能不改就跑,例外也不难对付。他给的性能数据点是近 9000 个密码学微基准(Zen 4 单核钉死),Fil-C 编译的代码通常比 clang 多花 1× 到 4× 的周期。为了让这套东西落地,他做了 Filian 来把 Debian 包逐个改用 Fil-C 编译,另有人做 Filnix 适配 Nix;构建本身吃内存,12GB 内存的机器得靠 36GB swap 才不中断,128 核 512GB 的机器则是 Fil-C 8 分钟、musl 6 分钟。他自写的 build-parallel.py 一轮跑完 61 个目标、101 分钟,成功 60 个——libcap 因 liblto_plugin.so 加载失败未过,util-linux 因 taskset 走 syscall 需要打补丁。文中还记了 vfork 不支持、b2 触发参数大小不匹配的安全报错、以及用 gcshim 顶替 libgc 等细节。
🔑 核心要点
- 兼容性评价很高:大量库与应用不改就能在 Fil-C 下跑,例外也不难修
- 代价是周期数:近 9000 个密码学微基准上,通常比 clang 多花 1× 到 4× 的时钟周期
- 落地靠打包层:Filian 把 Debian 包改用 Fil-C 编译,Filnix 负责 Nix 一侧
- 构建吃内存是硬门槛:12GB 内存的机器需要 36GB swap 才不中断,大机器上 Fil-C 编译 8 分钟
- 批量构建的现实数字:61 个目标、101 分钟,成功 60 个;libcap 卡在 liblto_plugin.so,util-linux 的 taskset 需要改补丁
- 坑位清单具体:不支持 vfork,b2 会触发「参数大小不匹配」的安全报错,libgc 可用调用 malloc 的 gcshim 顶替
💡 金句
我自私的目标是把我管理的那些机器切换到用 Fil-C 编译的代码上来保护它们,不过也许你也能在这里找到有用的东西。
👍 0
👎 0
← 返回 Lobsters 首页