Canonical 要把大规模 C 代码迁移到 Rust：难点不在翻译语法
据 Linuxiac 报道，Canonical 与英国布里斯托大学启动一项为期三年的研究项目，目标是开发一套把大型 C 代码库转换为更安全 Rust 实现的平台。项目计划以 AppArmor 和 snap-confine 等案例研究复杂系统代码，但并不意味着 Ubuntu 会立刻替换现有实现。
林岚
据 Linuxiac 报道，Canonical 与英国布里斯托大学启动一项为期三年的研究项目，目标是开发一套把大型 C 代码库转换为更安全 Rust 实现的平台。项目计划以 AppArmor 和 snap-confine 等案例研究复杂系统代码，但并不意味着 Ubuntu 会立刻替换现有实现。
大规模 C 到 Rust 的难点从来不是把关键字换成另一种写法。C 代码通常包含隐含的内存所有权、指针别名、宏展开、平台条件、构建脚本和未写进文档的 ABI 约束。自动翻译可以生成看起来合理的函数，但很难单独判断原实现依赖的生命周期和错误处理是否真的被保留。
项目采用神经符号混合思路，试图把大模型的代码生成能力和规则、程序分析、功能验证结合起来。代码会被分块处理，再通过测试和一致性检查确认行为。这个方向的关键不是让模型“猜得更像”，而是把无法证明的部分暴露出来，交给工程师继续处理。
即使迁移成功，Rust 也不能自动消除所有安全问题。内存安全缺陷可能减少，但权限设计、输入验证、逻辑错误、并发协议和供应链风险仍然存在。对于系统级项目来说，新旧实现并行验证、性能回归和兼容性维护，往往比第一版翻译更耗时。
Canonical 支持这一项目，说明 Linux 发行版厂商正在把 Rust 视为长期基础设施，而不仅是新项目的可选语言。但三年研究周期也提醒我们，自动迁移还处于工程化阶段。真正的成果应该是可复用的验证流程和迁移工具，而不是一次漂亮的代码演示。
关键事实
- 项目周期：三年。
- 参与方：Canonical 与英国布里斯托大学。
- 技术路线：神经符号混合、分块翻译和功能一致性验证。
- 案例方向：AppArmor、snap-confine 等复杂 C 代码。
OC 判断
C 到 Rust 的自动迁移真正要解决的是“如何证明没改坏”，而不是“能否生成 Rust 代码”。如果工具不能把语义不确定性、兼容性风险和未验证路径标出来，它只是在更快地产生新的维护负担。
为什么重要
- 对开发者：未来会出现更多半自动迁移工具，但测试和人工审查不会消失。
- 对企业：老旧 C 代码的安全改造可能从重写项目变成持续迁移流程。
- 对开源生态：Rust 的长期普及取决于能否降低存量代码迁移成本。
评论
围绕这篇文章补充信息、提出问题或分享观察。