C-to-Rust Translation System

• C-to-Rust translation systems are frameworks that convert C programs into Rust, ensuring memory safety and preserving functional semantics.
• They employ static analysis and hybrid LLM-guided pipelines to retype pointers and reduce the reliance on unsafe code, as seen in systems like Crown and PtrMapper.
• These systems achieve high semantic correctness and compilability by integrating formal ownership analyses with iterative LLM repair and test-driven validations.

A C-to-Rust translation system is a framework or toolchain designed to automate the lifting of legacy or modern C programs into Rust, with the goals of enhancing memory safety, idiomaticity, and maintainability while preserving functional semantics and performance. Such systems must bridge deep semantic, type-system, and ownership model differences, handle varied application domains (systems code, data structures, I/O, etc.), and operate at different scales—from individual functions to multi-megaline repositories. Approaches combine static analysis, program transformation, and increasingly, LLMs augmented by compile-time and runtime oracles.

1. Static- and Rule-Based Foundations

C-to-Rust translation originated with syntax-directed tooling such as C2Rust, which directly maps C constructs—pointers, malloc/free, unions, global vars—into equivalent, but typically non-idiomatic and heavily unsafe, Rust code. Enhancements in early research focused on semantic analyses to infer memory ownership, pointer mutability, and array "fatness," enabling partial lifting of raw pointers into safer Rust types.

The Crown system epitomizes this class with a three-stage pipeline: (1) C2Rust front-end and import resolution, (2) static analyses for ownership, mutability, and fatness; (3) pointer retyping and combinator-based rewriting. The key technical contribution is a formal, flow- and field-sensitive ownership analysis: each access path $p$ receives a Boolean variable $\mathbb{O}_p$—one iff it “owns” a referent. The system computes a SAT instance over these variables, subject to ownership monotonicity (ownership shrinks along pointer paths) and assignment/call/loop-generated move/no-move constraints. Solving this yields a global mapping: raw pointers are retyped if $\exists\,p.\,\mathbb{O}_p=1$ to Option<Box<T>>, otherwise to borrowing references or remain *mut T. Examples illustrate complete lifting of C list management to idiomatic, safe Rust; empirical benchmarks show 37.3% median reduction in raw-pointer declarations and 62.1% in pointer uses, with analysis/scaling to $5\times 10^5$ LOC in under 60 seconds on commodity hardware (Zhang et al., 2023).

Limitations include lack of handling for unions/variadics, absence of intra-procedure lifetime inference, and an ownership model occasionally stricter than Rust's, leading to false negatives in output-parameter patterns.

2. LLM-Based and Hybrid Translation Workflows

As LLMs achieved code generation fidelity across domains, translation research began to leverage models such as GPT-4o, Claude, Gemini, and DeepSeek. Pure LLM approaches struggle with context window constraints and semantic mismatches, often producing idiosyncratic or uncompilable Rust, especially for large or multi-file C projects.

Hybrid pipelines address these weaknesses by fusing static analysis and LLMs in multi-step translation architectures:

• SACTOR employs a two-phase translation: "unidiomatic" (functionally correct but possibly unsafe Rust via LLM+static hints), then "idiomatic" (iterative LLM-guided rewrites with static alias/mutability/ownership facts and end-to-end FFI-based test validation). This achieves up to 93% semantic correctness and strictly safe/idiomatic output on real test suites (Zhou et al., 16 Mar 2025).
• C2SaferRust and SafeTrans use C2Rust to generate unsafe Rust, then decompose into translation slices for LLM-based, context-aware repair, guided by static variable/type/usage analysis. Feedback on compilation/runtime errors is relayed to the LLM in few-shot or error-type-specific prompts, steadily reducing unsafe code (e.g., 28% reductions) while passing end-to-end tests. SafeTrans, in particular, extends this to formal security: 100% of detected C vulnerabilities (e.g., buffer overflow, use-after-free) are mitigated in Rust (Farrukh et al., 15 May 2025, Nitin et al., 24 Jan 2025).

LLM-prompt engineering incorporates:

• error-driven iterative repair,
• static facts (alias, mutability, pointer usage)—often encoded as formal structures,
• test-driven feedback or fuzzing-based oracles,
• instruction and in-context demonstration tailoring.

Coverage and correctness significantly surpass naive LLM prompting; compilation and test-passing rates increase by 20–50 percentage points on standard benchmarks when dynamic feedback loops and static cues are present.

3. Project-Scale Translation: Skeletons, Graphs, and Knowledge Integration

Moving to repository-scale translation amplifies challenges of pointer semantics propagation, modularity, API migration, and cross-file consistency. Recent systems introduce multi-stage pipelines to ensure scalable correctness and tractability:

• PtrMapper builds a project-wide C-Rust Pointer Knowledge Graph (KG) that encodes, for all pointer-bearing symbols (struct fields, vars, params), aliasing, points-to, ownership, mutability, nullability, and lifetime. Dependency SCCs are translated in dependency order, with LLM prompts parameterized by the KG slice relevant to each unit, enforcing consistent, globally valid pointer lifting (e.g., no drift between callers/callees or between function and struct context). Unsafe code and lint alerts are reduced by >90% compared to prior baselines, with a 29.3% increase in functional correctness on large benchmarks (Yuan et al., 13 Oct 2025).
• EvoC2Rust and Rustine employ skeleton-guided approaches: a full Rust skeleton (modules, macro/type definitions, function stubs) is derived via static analysis and type/macro mapping, guaranteeing successful compilation. Then, functions are incrementally filled by LLM or LLM+feature-mapping, with per-replacement compile-and-repair loops. EvoC2Rust demonstrates 98–99% code safety and 89–97% test pass rates in industrial and open benchmarks, outperforming both pure rule-based and LLM-only systems (Wang et al., 6 Aug 2025).
• Rustine applies preprocessing (macro expansion, pointer operation refactoring, const inference), AST-based decomposition, and LLM translation, followed by delta-debugging-based repair driven by tests and assertion tracing. The system achieves 87% assertion pass rates across 1.2M test assertions, with 100% compilability, minimal manual intervention (<5 hours per project in edge cases), and 95% reductions in raw pointers and unsafe code (Dehghan et al., 25 Nov 2025).

Empirical table (selected):

System	Unsafe Red.	Equiv. Rate	Compilability	Notable Feature
Crown (Zhang et al., 2023)	~37% ptrs	N/A	100%	Ownership SAT; monotonicity
SACTOR (Zhou et al., 16 Mar 2025)	100% unsafe	78–93%	78–100%	LLM + static facts + FFI validation
PtrMapper (Yuan et al., 13 Oct 2025)	99.9%	81.6%	98.3%	Knowledge graph-guided LLM translation
EvoC2Rust (Wang et al., 6 Aug 2025)	98%	89–97%	93–100%	Skeleton + feature mapping + repair chain
Rustine (Dehghan et al., 25 Nov 2025)	95%	87%	100