Canonical did not buy a tool to translate its C code into Rust. It funded a three-year PhD to find out whether that is even possible. If the company that maintains AppArmor and ships Ubuntu treats automated C-to-Rust translation as an open research question in August 2026, then the acceptance criteria in your legacy-modernization statement of work are almost certainly wrong — because the number every vendor quotes is compile rate, and compile rate is not a safety property.
On 19 August, Canonical's Engineering Vice President Jon Seager announced on the Ubuntu Community Hub that the company is co-funding doctoral research into automated C-to-Rust translation. Five days later The Register picked it up. The interesting part is not that Canonical is investing. It is what the investment implies about everything currently being sold as finished.
What Canonical Actually Funded
Canonical bought three years of research, not a migration. The funding is matched by UK Research and Innovation and supports a single PhD studentship at the University of Bristol, led by Professor Meng Wang with Dr Cristina David co-supervising and Alex Wood as the student. The industrial case studies are AppArmor and snap-confine — two of the security components Ubuntu's confinement model rests on.
The architecture Seager describes has four parts, and only one of them is the model: scheduling (splitting a repository into chunks that carry enough context to be translatable), translation, validation, and debugging and repair. The framing in the InfoWorld write-up is the line to take back to your vendor calls — generated code should be "treated as untrusted until there is evidence that it preserves the desired behavior."
Seager is precise about why the existing tooling is not enough. Deterministic source-to-source translators, he writes, "preserve the structure of the C too literally," so the result "may compile as Rust, but still rely heavily on unsafe operations, retain awkward C idioms and require significant manual work before it resembles code a Rust maintainer would choose to own." Large language models have the opposite failure: they produce "convincing, idiomatic Rust for small and well-defined examples" but "struggle with repository-scale context." His conclusion is the sentence that should end most sales meetings: "plausible-looking output is not evidence that the translated program behaves like its source."
The Register's coverage was openly doubtful that the hardest piece — decomposing a real repository into units a model can reason about correctly — generalizes much beyond narrow domains. The target Canonical names is programs "comprising hundreds of thousands of lines of C." That is a normal-sized daemon, not an extreme case.
The Numbers the Pitch Deck Leaves Out
The published research does not support the claim that automated C-to-Rust translation is a solved procurement decision. Three results, all from peer-reviewed or preprinted work, set the baseline any vendor claim has to beat.
Repository scale. CRUST-Bench is a dataset of 100 C repositories, each paired with a hand-written safe-Rust interface and test cases, built specifically to test whole-project transpilation rather than isolated functions. The number that gets quoted is the single-shot one: "The best performing model, OpenAI o1, is able to solve only 15 tasks in a single-shot setting." Quote it without that qualifier and you overstate the case. Give the models three rounds of test-based repair and the same benchmark's best result rises to 48 of 100 for OpenAI o3, with Claude Opus 4 at 40 and o1 at 37. Take 48 as the fair number. It still fails more than half of a benchmark curated to be tractable.
Correctness. RustAssure applied differential symbolic testing to LLM-transpiled code across five real applications and libraries. It generated compilable Rust functions for 89.8% of all C functions — and of those, only 69.9% "produced equivalent symbolic return values for both the C and Rust functions." Multiply it out: roughly 63% of the original functions both compiled and demonstrably behaved the same. The 89.8% is the number that goes in a slide. The 69.9% is the number that decides whether your AppArmor equivalent still denies what it used to deny.
Safety. C2SaferRust is the strongest published hybrid — run C2Rust first, then slice the unsafe output and have an LLM make each slice safer, verifying with end-to-end tests at every step. On a benchmark of 7 real-world programs it reduced raw pointers "by up to 38%" and unsafe code "by up to 28%," while still passing all tests. Read that as best case: at least 72% of the unsafe code survived.
None of this is a criticism of the researchers, and the frontier does move — the agentic results below are materially better than any of these three papers. What has not moved is the gap between what these systems are measured on and what a procurement contract needs proven.
Compiling Is Not a Safety Property
unsafe in Rust is a keyword that switches off the compiler's memory-safety checks for a block of code. A Rust program that is 60% unsafe has the syntax of Rust and the guarantees of C. This is not a subtlety the tool vendors invented around — the canonical transpiler says it plainly. The C2Rust README states: "The output of c2rust transpile is unsafe and unidiomatic; it is merely the first step in a longer migration process." Its own LLM postprocessor carries a warning that it "can introduce errors" and should be used with "a robust test suite."
So "it compiles" means the borrow checker was satisfied or bypassed. It says nothing about whether the program does what it did before.
DARPA has been funding exactly this problem since 2024. TRACTOR — Translating All C to Rust — aims to "achieve the same quality and style that a skilled Rust developer would produce, thereby eliminating the entire class of memory safety security vulnerabilities present in C programs." Evaluation is run independently by MIT Lincoln Laboratory. Look at what the first benchmark battery actually contains: Battery 01 "focuses on pointers with clear, well-defined lifetimes, avoids dynamic allocation and untyped pointers, and allows only controlled pointer arithmetic."
The flagship government programme, at its opening difficulty setting, excludes dynamic allocation and untyped pointers. Your codebase is made of dynamic allocation and untyped pointers.
Canonical Already Ran This Experiment, With Humans
The best available evidence for how hard behavioral equivalence is comes from Canonical itself, and it did not involve AI at all. Ubuntu 25.10 replaced GNU coreutils with the Rust uutils reimplementation — human-written, idiomatic, memory-safe Rust, produced by people with decades of documented GNU behavior to work from and a real test suite.
It still diverged, subtly, in production. Phoronix reported in September 2025 that differences between the two md5sum implementations broke Makeself self-extracting archives — taking VirtualBox, HPLIP and several benchmark installers down with them. Swapping back to the GNU package made the identical files work again.
The second one is the more instructive failure. The date command's -r/--reference flag, which reads a file's timestamp instead of the current time, was accepted by the argument parser and wired to no logic at all. It did not crash. It did not warn. It silently returned the wrong answer, which broke Ubuntu's own automatic update checks until a patched rust-coreutils shipped.
That bug is the exact shape of what Seager means by plausible-looking output. It compiles. It is memory-safe. Every guarantee the rewrite was undertaken for held. It passes review. And it is wrong in a way that only differential testing against the original binary would have caught. Humans did that, with the specification in hand. Ask what a model does with the same task and no specification, and then ask how your AI code review process would notice.
Microsoft Made the Big Claim and Walked It Back
The most aggressive claim anyone has made in this space was walked back by its author within days. In December 2025, Microsoft Distinguished Engineer Galen Hunt posted a hiring pitch for a team aimed at eliminating C and C++ from Microsoft by 2030, with the line: "Our North Star is '1 engineer, 1 month, 1 million lines of code'."
It travelled. Then Hunt amended the post: "Just to be clear… Windows is NOT rewritten with AI in Rust." He added: "My team's project is a research project. We are building tech to make migration from language to language possible." Coverage at the time noted Azure CTO Mark Russinovich had separately said Microsoft was "all-in on Rust" and working on "more automated translation from C and C++ to Rust using LLMs" — which is true, and is also a research statement.
Steel-manning the optimists: DARPA is funding this seriously, Microsoft has a real team on it, and the trajectory of tools like Blitzy's parallel coding agents and IBM's legacy modernization agents is genuinely steep. Long-horizon autonomous coding runs are producing real, inspectable commit histories.
The strongest counter-evidence to everything above is ORBIT, published in April 2026: an agentic framework that reports 100% compilation success, 91.7% test success, and unsafe code driven to roughly 0.06% of lines — against 69.6% for C2Rust in the same evaluation. That is a serious result, and far better than anything in the previous section. Read its evaluation before you quote it at a vendor, though: 24 programs selected from CRUST-Bench rather than all 100, chosen for size, with multi-threaded and GUI programs excluded — so it is not a like-for-like replacement of the 48-out-of-100 figure. And the authors name test quality as the ceiling on their own correctness claim. The team with the best published results in the field is telling you the tests are the limit of what they proved. That is Seager's sentence, from the other direction.
This will get better.
It is just not finished, and two of the three organisations best placed to finish it have publicly labelled their own work "research."
Your Memory Safety Roadmap Is Mostly About New Code
The mandate driving these purchases is real, and it does not ask you to rewrite anything. CISA and the FBI's Product Security Bad Practices guidance recommends that software manufacturers serving critical infrastructure publish a memory safety roadmap by 1 January 2026, outlining a prioritised approach to eliminating memory safety vulnerabilities in priority components. It is non-binding, it carries procurement weight, and it exempts products with an announced end-of-support date before 1 January 2030.
The roadmap elements themselves come from the earlier seven-agency guidance, The Case for Memory Safe Roadmaps, published December 2023 by NSA, CISA, FBI and their Australian, Canadian, New Zealand and UK counterparts. The list: defined phases with dates and outcomes, dates for memory safe languages in new systems, an internal developer training and integration plan, external dependency plans, transparency plans, and CVE support plans.
Notice what is not on that list. Nowhere does it say "translate the existing corpus."
Google's data explains why. Android's memory safety vulnerabilities fell below 20% of the total for the first time in 2025, down from around three-quarters six years earlier, and Rust code shows roughly a 1000x lower memory-safety vulnerability density than Android's C and C++ — with a rollback rate about 4x lower and 25% less time in code review. Google did that by writing new code in Rust, not by rewriting old code.
The mechanism matters more than the headline. As Google's security team put it, "Code matures and gets safer with time, exponentially, making the returns on investments like rewrites diminish over time as code gets older" — five-year-old code carries a 3.4x to 7.4x lower vulnerability density than new code.
Follow that through. Your oldest C is your most fuzzed, most patched, most battle-tested code. It sits at the bottom of the decay curve. Translating it produces brand-new, never-executed code, and resets that clock for every bug class the compiler does not catch.
The counter deserves stating plainly: a translation that genuinely lands in safe Rust retires the memory-safety class permanently, which maturity never does. That is the real case for doing it, and it is exactly the outcome the benchmarks above show is hardest to collect. Google's data is about how vulnerability density falls with code age; it says nothing about translated code in either direction. What it supports is narrower than the pitch — automated translation of a mature codebase is a low-return item on a memory safety roadmap, and it is the one item being aggressively sold to you.
What to Write Into the Statement of Work
This Week:
- Ask every vendor for a benchmark number and what it measures. CRUST-Bench and the TRACTOR batteries are public. If the answer is a compile rate or a "lines translated" figure, you have your answer about what they verified.
- Ask for the residual unsafe percentage on a codebase like yours — not a demo. Anything above single digits means you bought Rust syntax and kept C's guarantees.
- Stop treating "the tests pass" as the bar. The
date -rbug passed. So did every test that never exercised that flag.
This Month:
- Make differential testing the acceptance criterion. Two artefacts, both contractual: differential fuzzing of the translated binary against the original C binary on a shared corpus, and a coverage report proving every public flag, option and error path was exercised. Equivalence checking on the security-critical paths where it is tractable.
- Pilot on your smallest security-critical component with the best existing test coverage. Measure the human repair hours per thousand lines. That ratio — not the model's compile rate — is the only number that tells you whether this scales to the rest of your estate.
- Cap the repair loop. Iterative LLM repair against a compiler is the same pattern that regressed passing security checks in Terraform remediation, and translated code arrives with bigger diffs than a human reviewer can absorb. Set an iteration budget and a maximum reviewable diff before you start.
Before Your Roadmap Is Published:
- Put the new-code date first. Name the date after which new components in your priority code are written in a memory-safe language. It is the roadmap element with the best evidence behind it and the lowest execution risk.
- Budget humans for the security-critical rewrites. Canonical is spending three years of doctoral research on two confinement components. If that is a research project for the people who maintain them, the equivalent in your estate is not a purchase order.
The Bottom Line
Every prior modernization wave sold the same trade: the tool does the mechanical work, you keep the judgement. It was mostly true for COBOL screen-scraping and mostly true for the first round of cloud lift-and-shift, because in both cases a wrong answer showed up as a crash. Memory safety translation breaks the pattern. A wrong answer here compiles cleanly, satisfies the borrow checker, reads as idiomatic to a reviewer, and quietly stops enforcing a rule that used to hold — which is the one failure mode a compile rate can never detect.
Canonical could have bought a transpiler. It funded a question instead. Buy the evidence, not the compile rate.
Continue Reading
- OpenAI Picks Cognizant to Scale Codex Across Enterprises
- Agent Teams Hit 65 PRs a Week. Nobody Got Time Back.
- Best AI Coding Assistant at 500 Seats: Buy Copilot Business
- CISA Gave 3 Days to Patch Ray. Auth Is Still Off by Default.
- AI Wrote the S7 Exploit. There Is No CVE to Patch.
- Anthropic's Evals Maxed Out. Stop Inheriting Its Assurance.