内存安全圣战背后：数据打脸原教旨主义者，零点二比一千
内容提要
内存安全争论中，原教旨主义者视其为非黑即白，但数据显示Rust漏洞密度仅0.2/百万行，远优于C/C++的近千。Fil-C等新方案虽能防崩溃，却牺牲性能与兼容性。实用主义开发者权衡成本与效率，接受不完美，专注解决问题，而非追求理论上的绝对安全。
延伸解读
数据对比：0.2 vs 1000
文章引用了Google Android团队的数据：超过500万行Rust代码中仅发现1个潜在内存安全漏洞，密度为0.2/百万行；而C/C++的历史数据约为1000/百万行。这一千倍的差距直观展示了Rust在内存安全上的优势，但也需注意新项目可能因代码较新而问题较少。
Fil-C的代价与适用场景
Fil-C通过垃圾回收和InvisiCaps指针追踪实现内存安全，但代价包括与普通二进制不兼容、垃圾回收引入不确定暂停、性能可能慢数倍。这些代价对浏览器内核、游戏引擎等性能敏感场景不可接受，但对图片转换器等工具类程序则很划算。
崩溃与漏洞的权衡
Fil-C将越界访问转为崩溃，虽比远程代码执行漏洞好，但崩溃本身仍是故障，影响高可用服务，甚至可能被攻击者利用。Rust的“大部分安全”策略在编译期拦截多数问题，unsafe标记高危操作，更务实。
实用主义者的选择
多数项目无需在Fil-C和Rust间选择，它们用Go、Java、Python等语言也能良好运行。开发者应权衡内存安全、性能、开发效率等多重因素，而非追求绝对安全。文章强调，逻辑错误和需求变更的破坏力往往大于内存错误。
Q&A
Rust和C/C++的内存安全漏洞密度分别是多少？
根据Google Android团队的数据，Rust代码中每百万行约0.2个内存安全漏洞，而C/C++接近1000个，相差约一千倍。
Fil-C是什么？它如何实现内存安全？
Fil-C是一个新项目，旨在让C/C++代码自动获得内存安全。它通过结合垃圾回收和InvisiCaps指针追踪技术，在越界访问或释放后使用时直接让程序崩溃。
Fil-C有哪些缺点？
Fil-C的缺点包括：与普通编译的二进制文件不兼容，无法随意替换系统动态链接库；垃圾回收引入不确定的暂停，可能比内存泄漏更致命；性能可能慢几倍。这些代价对浏览器内核、游戏引擎等性能敏感场景不可接受。
为什么说内存安全不是非黑即白？
因为现实中的安全是权衡成本、性能、兼容性和开发效率的结果。例如，Fil-C能防崩溃但牺牲性能，而Rust通过unsafe标记高风险操作，在编译期拦截大部分问题，更务实。绝对安全可能导致极致的无用，如用Coq写操作系统可能下世纪才能开机。
Rust的unsafe关键字是否意味着不安全？
Rust的unsafe关键字用于标记需要绕过安全检查的高危操作，但Rust在编译阶段拦截了绝大多数问题，unsafe让审查有迹可循。安全原教旨主义者认为unsafe是开后门，但Rust的“大部分安全”策略更务实。
实用主义开发者如何看待内存安全？
实用主义开发者不站队，他们权衡各种指标，如代码可读性、社区活跃度、库完善程度等。他们接受技术的不完美，愿意用Rust的编译时长换取运行时稳定，也会关注Fil-C等新工具，但只解决问题，不追求理论上的绝对安全。
为什么说崩溃比被黑好，但依然是一种故障？
崩溃（如Fil-C将越界访问转为崩溃）比远程代码执行漏洞好，但崩溃仍会导致服务不可用，需要人工修复，且攻击者可能利用崩溃进行拒绝服务攻击或绕过安全机制。因此，崩溃不是完美的解决方案。
