&inator: Correct, Precise C-to-Rust Interface Translation

Abstract: Automatically translating system software from C to Rust is an appealing but challenging problem, as it requires whole-program reasoning to satisfy Rust's ownership and borrowing discipline. A key enabling step in whole-program translation is interface translation, which produces Rust declarations for the C program's top-level declarations (i.e., structs and function signatures), enabling modular and incremental code translation. This paper introduces correct, precise C-to-Rust interface translation, called &inator. &inator employs a novel constraint-based formulation of semantic equivalence and type correctness including borrow-checking rules to produce a Rust interface that is correct (i.e., the interface admits a semantics-preserving implementation in safe Rust) and precise (i.e., it uses the simplest, least costly types). Our results show &inator produces correct, precise Rust interfaces for real C programs, but support for certain C features and scaling to large programs are challenges left for future work. This work advances the state of the art by being the first correct, precise approach to C-to-Rust interface translation.

• The paper introduces a constraint-based methodology ensuring semantic-preserving and safe C-to-Rust interface translation.
• It leverages LLVM IR and SMT constraint solving with Z3 to synthesize Rust types that meet ownership, borrowing, and aliasing invariants.
• Empirical results demonstrate that &INATOR outperforms LLM and mechanical translators by eliminating unsafe code in benchmark programs.

&INATOR: Constraint-Based, Correct and Precise C-to-Rust Interface Translation

Problem Context and Motivation

Translating system software from C to memory-safe languages such as Rust is motivated by persistent, costly vulnerabilities arising from C's lack of memory safety. Rust, particularly its safe subset, enforces strong ownership and borrowing invariants, preventing common classes of bugs but fundamentally complicating mechanical migration from C. The foundational step in a modular, tractable migration pipeline is interface translation: given a C program, generate Rust declarations for all top-level entities (structs, function signatures, and globals) that both respect Rust’s ownership/borrowing discipline and maintain behavioral equivalence.

Existing approaches to interface translation are insufficient. LLMs can produce idiomatic Rust but often emit interfaces incompatible with Rust's safety guarantees due to local reasoning and lack of global alias analysis. Mechanical translators mostly yield unsafe Rust or fail in the presence of nontrivial aliasing. Prior benchmarks for C-to-Rust translation distribute hand-crafted interfaces, underlining the current lack of a robust automated solution.

&INATOR: Constraint-Based Interface Synthesis

Approach Overview

&INATOR addresses C-to-Rust interface translation as a constraint satisfaction problem over global program semantics. It consumes LLVM IR, infers source types, and generates an SMT problem capturing the following requirements:

• Correctness: The Rust interface must admit a semantics-preserving, safe Rust implementation for the original C code, modulo certain dynamic conflicts and memory leaks.
• Precision: Among admissible interfaces, the chosen types minimize cost based on mutability, pointer indirection, runtime overhead, and interface complexity.

Type synthesis accounts for Rust-specific invariants—ownership, borrowing, lifetimes, copy/move semantics, and recursive type soundness—alongside semantic equivalence at the level of copying and aliasing.

Constraint Generation

The translation proceeds as follows:

1. Program Normalization: The C input is lowered to LLVM IR and then mapped to a C-like source language, making pointer and lifetime operations explicit. Each top-level declaration and relevant program value is tagged with a unique label.
2. SMT Constraint Encoding: Type assignments (including Rust fragment types, qualifiers, and lifetimes) for each label induce constraints enforcing: type parity with the C source, correct ownership/borrowing for pointers, well-formed struct definitions, non-violation of Rust’s move and borrow-checker invariants, and aliasing correctness. The analysis exploits pointer transformation edges (e.g., raw to Rc<RefCell<_>>, Box<_>, reference, etc.) to allow for implicit “upgrades” at usage sites, increasing precision without sacrificing safety.
3. Solving and Type Extraction: The system is discharged using Z3, yielding assignment of Rust types to all interface and internal variables.

Minimizing the number of interior mutability wrappers (Cell, RefCell), pointer indirection layers, and reference lifetimes are encoded as priorities in the objective.

Properties and Guarantees

• Whole-program Globality: Translation requires global (whole-program) reasoning. It is strictly non-modular but enables modular translation of function bodies post-facto.
• Alias Soundness: The generated interfaces preserve aliasing as in the original C.
• Correctness Under Constraints: For C code without undefined behavior, &INATOR guarantees correctness up to specified limitations (e.g., dynamic borrow conflicts, memory leaks in presence of reference cycles).
• Precision: The cost-model ensures that interfaces do not gratuitously add indirection or permissivity.

Evaluation and Results

&INATOR was implemented as an LLVM analysis and Rust/Z3 constraint solver. Empirical evaluation focused on C programs drawn from CRUST-Bench and hand-written examples, targeting interface soundness, precision, and performance.

• Correctness/Precision: Across evaluated benchmarks (e.g., list manipulation, red-black trees, message encoding), &INATOR synthesized interfaces for all tested programs that enabled the production of safe Rust translations, matching or exceeding the precision of manually written or benchmark-provided interfaces. It succeeded in eliminating unsafe types entirely, unlike C2Rust-based workflows.
• Scalability: For programs in the O(10^2–10^3) lines of code range (with thousands of instructions and hundreds to thousands of interface variables), analysis (constraint generation) was fast, but Z3 constraint solving scaled superlinearly, requiring several hours for the largest benchmarks. Key bottlenecks were constraint count explosion for large monolithic functions.
• Limitations: C features such as function pointers, polymorphic void pointers, unions, and some type casts are unhandled. Multi-threaded code and libraries lacking usage examples are out of scope. Dynamic borrow conflicts (e.g., conflicting RefCell::borrow/borrow_mut) are not fully ruled out and may induce panics in the Rust translation.

Comparative Analysis

&INATOR outperforms LLM-based and mechanical translators in interface soundness and precision. Existing systems either produce copious unsafe code, fail to respect complex aliasing, or rely on hand-written interface adaptation. Whereas C2Rust and derivatives leave most pointer-based parameters as raw pointers or unsafe blocks, &INATOR eliminates these by sound type assignment. Compared with hand-written benchmarks (CRUST-Bench), &INATOR interfaces diverge only when necessary to maintain semantic parity (copy semantics, idiomatic translation differences like &[u8] vs &str).

Implications and Future Directions

This work demonstrates that constraint-based interface synthesis can bridge C and Rust’s vastly different type disciplines, making modular and incremental migration viable without extensive unsafe code or hand intervention. It opens paths towards integrating such analyses with LLM-based code translation by first generating sound interfaces, then translating bodies modularly with correctness guaranteed at the module boundary.

In practice, the approach is currently limited by scaling issues and partial C language coverage, but refinements (e.g., compositional analysis, improved constraint factoring, incremental solving) could enable much larger codebases. Extending the cost-model to include idiomaticity and advanced type wrappers would further improve real-world applicability. Additionally, relaxing strict alias preservation, with user or analysis-guided semantic refactorings, could yield even more precise/simpler interfaces where legacy C code relies on convoluted pointer idioms.

Conclusion

&INATOR introduces a rigorous, constraint-based methodology for C-to-Rust interface translation. By encoding both semantic preservation and Rust’s safety invariants as global type constraints, it achieves what previous systems have not: sound, precise, compositional interfaces for C code, fully eliminating the need for unsafe Rust in translated code, modulo expressiveness of Rust’s type system. The results suggest that automated, trustworthy migration of legacy system software to safe languages is an attainable goal—contingent on advances in scalability and coverage of legacy C idioms.

---

Reference: "&INATOR: Correct, Precise C-to-Rust Interface Translation" (2604.17261)