Why C-to-Rust Translation Is a Semantic Problem

The C-to-Rust research case examines the hardest part of the migration seam: turning legacy behavior into Rust types that express what the program means, not merely how its declarations look. The specific judgment is whether an automated translator has understood ownership, failure, and caller expectations well enough to produce a genuinely safer target. The answer begins with a constraint: a C type name is not a complete description of the relationship it represents.

One pointer, several meanings

In C, a pointer can be used for several jobs. It can point to storage that a function may modify. It can act as an optional output location. It can signal that an operation succeeded or failed. It can represent a value whose lifetime is managed elsewhere. The same surface type can therefore hide different contracts.

The paper illustrates this with two functions that both use an integer pointer. In the first, the function receives a pointer, increments the integer it points to, and returns the updated value. A natural Rust interpretation is a mutable reference to an integer: the caller lends valid storage, the function may change it under the reference rules, and the function returns the result. The pointer’s essential meaning is controlled mutation of an existing value.

The second function uses an integer pointer differently. It takes two numbers and a pointer for an output quotient. When the divisor is zero, it writes nothing and returns a failure indicator. Otherwise, it writes the quotient through the pointer and returns success. In an idiomatic Rust design, the result can become an option-like return value: absence represents failure, while presence carries the quotient. The pointer disappears from the parameter list and its value moves into the return type.

Those two interpretations are not cosmetic alternatives. They change who owns storage, how failure is represented, how the function body branches, and what the caller must do with the result. A fixed mapping from C int * to one Rust type would be wrong for at least one of the functions. A translator must inspect the function’s behavior and choose among target types based on semantics.

This is the m-to-n problem described by the paper. One C type can map to several Rust types depending on context, and several C types can converge on a Rust representation that better expresses their shared behavior. The relationship is not a dictionary from names to names. It is an interpretation of a contract.

That distinction matters for memory safety. A C pointer carried into Rust as a raw C-style pointer may preserve the old surface but leave the Rust type checker with less information about valid dereferencing. A reference, option-like result, slice, or other Rust type can express a stronger relationship when the source behavior supports it. But introducing a stronger type is safe only if it is the right interpretation. A wrong type can make code appear modern while misrepresenting failure or ownership.