Pith. sign in

REVIEW 5 major objections 5 minor 17 references

From C to Idiomatic Rust: A Ship-of-Theseus Agentic Translation

T0 review · 5 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that C-to-Rust migration is reliably done as a sequence of small, test-verified rewrites starting from a semantics-preserving non-idiomatic baseline, and demonstrates it on a 12.5k-line DNS tunnel in 37 developer-hours.

desk verdict A well-argued engineering case study whose 'reliable preservation' claim outruns its validation; still worth reviewing if artifacts ship. read the letter →

arxiv 2607.28835 v1 pith:54BUNDWI submitted 2026-07-30 cs.SE cs.OScs.PL

Vasily A. Sartakov This is my paper
classification cs.SEcs.OScs.PL
keywords C-to-RustmigrationagenticAIincrementalrefactoringsemanticpreservationbehavioraltestingidiomaticRustiodineDNStunnelmemorysafety
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Most C-to-Rust translation tools try to convert C directly into idiomatic Rust in one step. This paper argues for the opposite: first mechanically produce a Rust program that preserves C semantics but is deliberately non-idiomatic, then incrementally rewrite it function by function into idiomatic Rust, checking compilation and runtime behaviour after every change. The paper demonstrates this "ship-of-theseus" workflow on iodine, a production DNS tunnel of roughly 12.5k lines of C, and reports a final Rust implementation of about 10.3k lines with no unsafe extern "C" declarations and no static mutable globals, reached in about 37 developer-hours. The result matters because it suggests that migrating long-lived C systems to safer languages can be planned as a verification problem rather than a high-risk rewrite.

What carries the argument

The load-bearing mechanism is the gate cycle combined with leaf-first dependency ordering. Each candidate function rewrite must pass Gate A (compilation with the paper's five idiomaticity criteria C1–C5 enforced as hard errors) and Gate B (running the system under a realistic sustained workload; on any divergence, old and new implementations are instrumented with equivalent traces, the divergence is fed back to the language model, and the loop repeats). A static call graph selects leaf functions first, so each transformation rests on already-verified safe code. The two-phase separation—first converting function signatures and bodies (C1, C2, C4, C5), then wrapping static mut globals (C3) one

What would settle it

Run the workflow on a C program with a deliberately sparse test suite and known edge-case behavior (integer overflow, off-by-one pointer arithmetic); if Gate B passes yet differential fuzzing of the original and translated binaries finds any divergence, the claim of reliable migration under this methodology is falsified.

Watch

Extended reading notes

Core claim

The central claim is that a semantics-preserving but non-idiomatic Rust baseline, once generated mechanically from C, can be transformed into idiomatic Rust by an agentic AI loop that replaces one function at a time, provided every replacement passes two gates: Gate A (compilation plus the paper's five idiomaticity criteria—no unsafe in signatures, slice-based buffers, no static mut, no extern "C" on internal functions, no C string/memory routines) and Gate B (running the whole system under a realistic workload and, on divergence, feeding trace differences back to the model for revision). The method was applied to the iodine DNS tunnel: starting from transpiler output with 178 unsafe extern

Load-bearing premise

Everything rests on the assumption that the existing test workload plus sustained real-traffic runs is a sufficient oracle for semantic equivalence, so behavior preservation is only demonstrated on the tested input space, not proven for all inputs.

Editorial extensions

If this is right

  • Large C systems can be migrated in days rather than months: the study reports 37 developer-hours for 12.5k SLOC, an average of 4.5 translated functions per hour.
  • A mechanically transpiled, semantics-preserving baseline is a viable starting point; the actual work becomes staged refactoring with continuous verification rather than a single translation step.
  • The five idiomaticity criteria give an automated gate an explicit, checkable target for what counts as "idiomatic Rust", so progress can be measured and enforced.
  • Eliminating static mutable globals in a risk-ascending order (atomics first, then mutexes, one global at a time) avoids silent deadlocks that compiler checks miss; batching mutex wrappers produced live deadlocks in the study.
  • The two-phase structure—function-level changes before global-state wrapping—keeps lock-order analysis tractable, suggesting the workflow can scale to projects of comparable complexity.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The method's equivalence guarantee is only as strong as the runtime oracle it uses; adding differential fuzzing or property-based testing to Gate B would directly address the largest remaining gap in semantic-equivalence checking.
  • The leaf-first, gate-verified incremental pattern is a general recipe for agentic refactoring, applicable beyond C-to-Rust to any large-scale code modernization where an executable oracle exists.
  • The RUST% plateau at 57% suggests that raw pointer arithmetic inside function bodies is the hardest residue to eliminate; targeted ownership-inference analysis on the remaining operations might push the score higher.
  • The thin FFI adapter scaffolding—converting raw pointers to slices so safe Rust can be called from legacy C call sites—is a reusable intermediate representation for mixed-language systems.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper proposes a Ship-of-Theseus methodology for migrating C code to idiomatic Rust. It first uses the c2rust transpiler to obtain a compilable but non-idiomatic Rust baseline, then incrementally rewrites functions through an agentic LLM loop. Each transformation is checked by Gate A (compilation plus enforcement of five idiomaticity criteria C1–C5) and Gate B (running the system under a realistic workload for a sustained period). The methodology is evaluated on the iodine DNS tunnel (~12.5 kSLOC). The authors report 37 developer-hours of effort, final scores of SAFE%=96% and RUST%=57%, with no remaining unsafe extern "C" functions or static mut in the evaluated code. The paper contributes an explicit decomposition of C-to-Rust migration into verifiable per-function steps, a two-phase ordering (function bodies first, global state second), and a detailed case-study narrative.

Significance. If the claims hold, this is a useful practical contribution: it demonstrates that large-scale C-to-Rust migration can be decomposed into a sequence of individually validated function rewrites, and it makes the idiomaticity targets explicit through C1–C5. The case study with commit-level trajectories and concrete initial/final counts is valuable for practitioners. However, the paper's strongest claim—that the migration is 'reliable' and 'correctness-preserving'—rests on an under-specified behavioral oracle (Gate B). The absence of the final source code, test harness, and logs prevents independent verification. The SAFE% and RUST% metrics are also internally inconsistent in a way that weakens the quantitative evaluation. These issues are fixable in revision, but they currently prevent the paper from being accepted as an archival validation of the methodology.

major comments (5)
  1. [§4.3, Eq. (1)] The reported SAFE% metric is arithmetically inconsistent. The initial counts are XCFN=178 and NMGL=73, so the denominator in SAFE% is 251. Phase 2 states that '184 declaration-level unsafe extern "C" fn sites eliminated' and 'the 5 remaining are signal handler type definitions'. If 5 remain, then 246 sites were eliminated, not 184, and SAFE% would be 98%, not 96%. Conversely, if 184 sites were eliminated, 67 remain, giving SAFE% ≈ 73%. The same paragraph later says 'no unsafe extern "C" fn declarations' in the final implementation, which contradicts the '5 remaining' claim. Please reconcile these numbers and clarify what exactly XCFN and NMGL count (function declarations, annotations, or both). Without a coherent metric, the headline 'SAFE% = 96%' is not reproducible.
  2. [§3.2, Gate B and §6 Future Work] Gate B is the only behavioral equivalence check between each old and new implementation, and it consists of 'run under a realistic workload for a sustained period processing real data'. As the paper itself concedes in Section 6, 'Combining runtime testing with static analysis, property checking, symbolic execution, or automated test generation could provide stronger correctness guarantees.' The current oracle cannot establish semantic equivalence beyond the tested input space; it exercises only the representative workload for a DNS tunnel, not the full state space (e.g., malformed packets, timeout/retry branches, concurrency interleavings). The abstract and conclusion describe the migration as 'reliable' and 'correctness-preserving', which is stronger than the evidence supports. Please either strengthen the validation (e.g., differential fuzzing against the C original or the c2rust basel
  3. [§4.2] The paper emphasizes 'agentic AI' but the case study shows substantial human involvement: deduplicating c2rust struct definitions, writing thin_ffi adapters, deciding to replace getopt() with a Rust parser, and manually reverting to one-at-a-time Mutex wrapping after a deadlock. Section 4.2 says 'Most of them required the involvement of a human and prevented fully-automated agentic translation.' The 37 developer-hours is total effort, but there is no breakdown of how much was manual vs. automated and no description of what the LLM actually did beyond 'describe and implement' and 'revision on trace divergence'. Please quantify the human effort and clarify which steps are automated versus mediated by the human. This is needed to support the 'agentic' framing.
  4. [General reproducibility] The paper does not provide the generated Rust source code, the test harness, the workload configuration, the exact trace-diagnostic tool, or any logs. For an empirical SE case study, the absence of artifacts makes it impossible to audit the claimed metrics (SAFE%=96%, RUST%=57%) or the behavioral tests. At minimum, the final artifact and the test harness should be made available (e.g., in a repository). Please include an artifact availability statement and, if possible, the commit history used to produce Figure 3.
  5. [§3.2, Gate A] Gate A is described as enforcing the idiomaticity criteria C1–C5 as 'hard errors', but the implementation of this checker is not specified. How are C1–C5 checked automatically? Is it a manual code review, a static-analysis tool, or part of the LLM prompt? If only the LLM prompt and the human review enforce them, then Gate A is not a reproducible gate. Please describe the mechanism that actually enforces these criteria.
minor comments (5)
  1. [Throughout] Several typos and incomplete sentences: 'resilt' (§2.1), 'intermadate' (§3.2), 'fever iterations' (§4.3 Models), 'These temporary solution was removed' (§4.2), and an unfinished sentence in §3.2: 'The building infrastructure responsible for compilation of the project in various configurations...' Please proofread carefully.
  2. [ACM template] The 'CCS Concepts' section still contains placeholder text: 'Do Not Use This Code → Generate the Correct Terms for Your Paper'. This is a template leftover and must be replaced before submission.
  3. [Abstract] The title and abstract use the 'Ship-of-Theseus' metaphor, but the metaphor is never explained in the body. A brief explanation would help readers understand the incremental replacement framing.
  4. [§3.2, §4.2] The distinction between 'verified baseline' and the runtime tests is unclear. In §3.2, the baseline is called 'Verified Baseline', but later in §4.3 the 'initial c2rust-generated code' is used as the reference. Please define what 'verified' means at baseline and whether the initial c2rust output is itself tested against the C original.
  5. [§6 Future Work] The Future Work section is thorough, but the first item 'migration orchestration' acknowledges that the current workflow relies on human judgment. This is worth emphasizing earlier in the paper, because it qualifies the 'agentic' claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the validation oracle is external, the metrics are bookkeeping, and no load-bearing self-citation appears.

full rationale

The paper is a workflow/case-study report, not a derivation whose conclusion is encoded in its inputs. The load-bearing equivalence check, Gate B, is explicitly a differential test against the original C program: 'production the same output and state modification for the same input.' This is an external oracle, not a self-defined prediction. The idiomaticity criteria C1–C5 are independently stated design targets (no unsafe in signatures, slices, no static mut, no extern "C" on internal functions, no C string/memory functions); meeting them is the paper's goal, not a circular derivation. SAFE% and RUST% are tracking metrics computed from defined artifact counts (XCFN, NMGL, PtrA, D-UNS); the reported final values are observed outcomes of the process, not fitted parameters renamed as predictions. The paper explicitly acknowledges the limitation that compilation and behavioural testing are not formal proof, in Future Work: 'Combining runtime testing with static analysis, property checking, symbolic execution, or automated test generation could provide stronger correctness guarantees.' That is a strength-of-evidence caveat, not a circular step. All cited tools and prior work are external; there is no self-citation chain that carries the central claim. No equation or definition reduces the claimed result to its own input. Under the required standard—exhibiting a specific constructional reduction—no circularity can be identified.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

No new physical or theoretical entities are introduced. The paper's assumptions are software-engineering judgment calls: trust in c2rust's preservation property, the adequacy of the test oracle, the self-defined idiomaticity criteria, and the relevant baseline for effort comparison. The main load-bearing parameters are the behavioral oracle and the LLM choice/version distribution.

free parameters (2)
  • Behavioral oracle (existing iodine test workload + sustained traffic) = Not a named value; defined by the iodine test suite and the specific traffic pattern used to validate Gate B.
    The equivalence guarantee is only as strong as the chosen test workload. The paper validates against realistic workload but does not provide an independent fuzz/symbolic oracle, so the tested input space is itself a parameter of the claim.
  • Model choice (Qwen3.6-27B reported best) = Qwen3.6-27B
    The claimed throughput and number of iterations depend on which LLM is used, and the paper states model choice was varied during development without controlled experiments. This makes the 4.5 functions/hour figure tied to an unstated distribution of models/versions.
assumptions (4)
  • domain assumption c2rust (as cited) produces a semantics-preserving lossless translation of pure C to non-idiomatic unsafe Rust.
    The entire methodology's verified baseline presumes c2rust preserves control flow, data flow, and memory model of the original C (stated in §2.1). The paper treats c2rust's behavior as given, not re-verified.
  • domain assumption Compilation plus the existing iodine test workload and sustained runtime constitutes a sufficient semantic-equivalence oracle.
    Gate B (§3.2, 'pass' conditions) validates behavioral equivalence only on the chosen harness/traffic. No formal equivalence, differential fuzzing, or exhaustive test generation is claimed.
  • ad hoc to paper The paper's five idiomaticity criteria C1-C5 are the correct and sufficiently complete definition of idiomatic Rust for the migration goal.
    C1-C5 are stated in §3.1 as the authors' own reference standard. They are reasonable but are the paper's own invention, so the claim that the result is 'idiomatic' is relative to this self-defined standard.
  • domain assumption COCOMO II estimates for de novo development are a meaningful baseline for interpreting migration productivity.
    COCOMO II estimates effort for new development (cited in §4.3), not migration. The estimated 'several tens of person-months' context is an interpretation the rhetorical force of §4.3 depends on.

how reviews work

0 comments
Cite this review

Pith. "Pith review of From C to Idiomatic Rust: A Ship-of-Theseus Agentic Translation." pith.science (2026). https://pith.science/paper/54BUNDWI

@misc{pith2026260728835,
  author       = {Pith},
  title        = {Pith review of: From C to Idiomatic Rust: A Ship-of-Theseus Agentic Translation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/54BUNDWI}},
  note         = {Machine review of arXiv:2607.28835}
}
read the original abstract

C underpins operating systems, embedded platforms, and network infrastructure because its abstractions map directly to machine behaviour. Its explicit memory model, predictable data representations, and minimal runtime allow compilers to generate fast, deterministic code. These properties also leave correctness and memory safety entirely to the programmer, making undefined behaviour, pointer misuse, and lifetime errors persistent sources of defects and security vulnerabilities in long-lived C codebases. Rust eliminates most of failure modes through a static ownership and borrowing model that enforces memory safety and aliasing constraints at compile time. However, mature C systems cannot be translated directly: implicit layout assumptions, aliasing patterns, and undefined behaviour must be reconstructed before safe Rust can be produced. This paper presents a migration methodology that first generates a semantics-preserving, non-idiomatic Rust baseline and then incrementally rewrites it into idiomatic Rust using agentic AI, validating each step through compilation and behavioural testing. Applied to iodine (12.5k SLOC), the approach demonstrates that reliable C-to-Rust migration is a structured transformation workflow rather than a single translation step.

Figures

Figures reproduced from arXiv: 2607.28835 by the authors.

Figure 1
Figure 1. Three versions of the same DNS name decoding function. The c2rust version preserves C’s raw pointer semantics and [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. The gate cycle. Each transformation passes through two gates: compilation (A) and runtime verification (B). When [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Decreasing the amount unsafe code with project progress [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

17 extracted references · 1 linked inside Pith

  1. [1]

    2009.Software cost estimation with COCOMO II

    Barry W Boehm, Chris Abts, A Winsor Brown, Sunita Chulani, Bradford K Clark, Ellis Horowitz, Ray Madachy, Donald J Reifer, and Bert Steece. 2009.Software cost estimation with COCOMO II. Prentice Hall Press

    2009

  2. [2]

    Xuemeng Cai, Jiakun Liu, Xiping Huang, Yijun Yu, Haitao Wu, Chunmiao Li, Bo Wang, Imam Nur Bani Yusuf, and Lingxiao Jiang. 2025. Rustmap: Towards project-scale c-to-rust migration via program analysis and llm. InInternational Conference on Engineering of Complex Computer Systems. Springer, 283–302

    2025

  3. [3]

    Saman Dehghan, Tianran Sun, Tianxiang Wu, Zihan Li, and Reyhaneh Jabbarvand

  4. [4]

    Mehmet Emre, Peter Boyland, Aesha Parekh, Ryan Schroeder, Kyle Dewey, and Ben Hardekopf. 2023. Aliasing limits on translating C to safe Rust.Proceedings of the ACM on Programming Languages7, OOPSLA1 (2023), 551–579

    2023

  5. [5]

    Hasan Ferit Eniser, Hanliang Zhang, Cristina David, Meng Wang, Maria Chris- takis, Brandon Paulsen, Joey Dodds, and Daniel Kroening. 2025. Towards Translating Real-World Code with LLMs: A Study of Translating to Rust. arXiv:2405.11514 [cs.SE] https://arxiv.org/abs/2405.11514

    arXiv 2025

  6. [6]

    2019.Modern C(2 ed.)

    Jens Gustedt. 2019.Modern C(2 ed.). Manning Publications

    2019

  7. [7]

    Jaemin Hong and Sukyoung Ryu. 2024. Don’t write, but return: Replacing output parameters with algebraic data types in c-to-rust translation.Proceedings of the ACM on Programming Languages8, PLDI (2024), 716–740

    2024

  8. [8]

    Jaemin Hong and Sukyoung Ryu. 2024. To tag, or not to tag: Translating c’s unions to rust’s tagged unions. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 40–52

    2024

Show all 17 references
  1. [9]

    Jaemin Hong and Sukyoung Ryu. 2025. Forcrat: Automatic I/O API Translation from C to Rust via Origin and Capability Analysis.arXiv preprint arXiv:2506.01427 (2025)

    2025

  2. [10]

    Kernighan and Dennis M

    Brian W. Kernighan and Dennis M. Ritchie. 1988.The C Programming Language (2 ed.). Prentice Hall

    1988

  3. [11]

    Erik Kristensen, Peter Korley, Anders Andersen, Zvonimir Pavlinovic, Thomas Wies, and Shuvendu K. Lahiri. 2022. C2Rust: A Tool for Migrating C Code to Rust. InProceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). ACM

    2022

  4. [12]

    Momoko Shiraishi, Yinzhi Cao, and Takahiro Shinagawa. 2024. SmartC2Rust: Iterative, Feedback-Driven C-to-Rust Translation via Large Language Models for Safety and Equivalence.arXiv preprint arXiv:2409.10506(2024)

    2024

  5. [13]

    Chaofan Wang, Tingrui Yu, Beijun Shen, Jie Wang, Dong Chen, Wenrui Zhang, Yuling Shi, Chen Xie, and Xiaodong Gu. 2025. Evoc2rust: A skeleton-guided framework for project-level c-to-rust translation.arXiv preprint arXiv:2508.04295 (2025)

    2025

  6. [14]

    Zhen Yang, Fang Liu, Zhongxing Yu, Jacky Wai Keung, Jia Li, Shuo Liu, Yifan Hong, Xiaoxue Ma, Zhi Jin, and Ge Li. 2024. Exploring and unleashing the power of large language models in automated code translation.Proceedings of the ACM on Software Engineering1, FSE (2024), 1585–1608

    2024

  7. [15]

    Hanliang Zhang, Cristina David, Yijun Yu, and Meng Wang. 2023. Ownership guided C to Rust translation. InInternational Conference on Computer Aided Verification. Springer, 459–482

    2023

  8. [16]

    Han Zhou, Yu Luo, Mengtao Zhang, and Dianxiang Xu. 2025. C2RustTV: An LLM-based Framework for C to Rust Translation and Validation. In2025 IEEE 49th Annual Computers, Software, and Applications Conference (COMPSAC). 1254–1259. doi:10.1109/COMPSAC65507.2025.00158

    2025

  9. [2025]

    Translating Large-Scale C Repositories to Idiomatic Rust.arXiv preprint arXiv:2511.20617(2025)

    2025

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.