Rust 想要 extern "fil-c" 安全桥接
I want extern "fil-C"
Rust 的 C FFI 虽然能利用大量遗留软件，但代价是必须跨过 unsafe 边界，将内存安全寄托于无法强制执行的 C 库合同。Fil-C 项目提供了一种新方案：它通过运行时检查和并发垃圾回收，将 C 和 C++ 代码重编译为内存安全版本。我渴望构建一个支持 extern "fil-c" 的 Rust FFI，让 Rust 负责编译期安全，而 Fil-C 负责运行时安全。这样，保留旧 C 库时指针操作会被检查，而将热点路径重写为 Rust 后，这些开销将消失。filnix 已为 Fil-C 提供了 Nix 交叉编译平台，Zig 也在探索类似的 fil ABI。我们需要 Rust、Fil-C、Zig 和 Nix 社区携手合作，在 OceanSprint 上共同构建这座桥梁，让 C 成为安全的兼容路径，而非永久的快速路径。
C 将成为安全的兼容路径，而非永久的快速路径。
HN 评论区
39- andai
为什么 fil-C 的 ABI 不与 C 兼容？
看来这是有意为之。给出的理由是：我们不想允许在 fil-C 程序中使用非安全的 C 代码。这倒也能理解。
但为什么我们要阻止 Rust（或者干脆说 C）调用 fil-C 程序呢？
我对编译器不太懂，但我猜允许其中一种调用，另一种也就顺理成章了？也就是说，不可能做到既让 fil-C 的 ABI 与 C 兼容（以便更容易被调用），同时又禁止从 fil-C 内部调用 C 代码吧？
- pornel
Mozilla 在生产环境中针对遗留 C 编解码器有一个解决方案：
它不能替代 Fil-C 作为精确的 ASAN/Valgrind 的角色，但如果你想在调用 C 库的同时，不让它随意污染调用方的内存，那它效果非常好。