Pith. sign in

REVIEW 3 major objections 5 minor 58 references

A training pipeline that combines rule-guided search with reinforcement learning can make LLM-generated C-to-Rust translations compile more often, pass execution tests more often, and rely on far less unsafe code.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-01 11:09 UTC pith:DVQC3GDY

load-bearing objection TRAVEL is a solid, well-engineered method paper for C-to-Rust translation that deserves referee time, but the headline 'ensures semantic preservation' outruns the evidence: the oracle is five LLM-generated tests per function. the 3 major comments →

arxiv 2607.19966 v1 pith:DVQC3GDY submitted 2026-07-22 cs.SE

Towards Reliable C-to-Rust Translation with Rule-Guided Reasoning and Reinforcement Learning

Feng Luo , Jiachen Liu , Cuiyun Gao , Jia Feng , Kui Liu This is my paper
classification cs.SE
keywords C-to-Rust translationlarge language modelsMonte Carlo Tree Searchreinforcement learningRust-specific rulessemantic preservationmemory safetyunsafe code
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper tries to establish that LLM-based C-to-Rust translation fails for two distinct reasons — models ignore Rust-specific rules like ownership and borrowing, and they miss subtle C semantics — and that both can be addressed in training. It proposes TRAVEL, a two-stage pipeline: a Monte Carlo Tree Search generates reasoning paths steered by a Rust rule library and scored by executing translations against generated test cases; then Group Relative Policy Optimization fine-tunes the model using a reward that combines execution feedback with a reasoning-quality signal. If this is right, a 7B-parameter model can surpass much larger open models and approach proprietary ones, while producing nearly zero unsafe code. The paper reports average gains of about 26 points in computational accuracy and 19 points in compilation success over the strongest prompting baseline on a public benchmark, with larger compilation gains and lower unsafe rates on Linux-kernel and industrial functions.

Core claim

The central claim is that reliable C-to-Rust translation is achievable by training a model to search over explicit reasoning paths before generating code, rather than translating in one shot. The search is steered at every step by a library of Rust-specific translation rules — ownership instead of malloc, Option instead of NULL returns, references instead of raw pointers — and every complete path is executed on a small suite of LLM-generated test inputs to decide whether it preserved behavior. The resulting paths and outcomes become training data for a reward model and for GRPO optimization with a dual reward: one term scores execution results, the other scores the reasoning path itself. The

What carries the argument

The load-bearing mechanism is the coupling of rule-guided MCTS reasoning-path search with dual-reward GRPO. MCTS treats each reasoning step as an action, uses Rust-specific rules as prompts to bias action priors, and assigns a binary terminal reward by executing the translation on five LLM-generated test inputs per C function; the backpropagated values give each path a score. A reward model is trained to predict that score from (C, reasoning path, Rust code), and GRPO optimizes the policy with a combined reward: execution reward (compile and test pass rate) plus reasoning reward (learned path quality). The two rewards are complementary — execution rewards observable behavior, reasoning rewar

Load-bearing premise

The load-bearing premise is that five LLM-generated test inputs per C function, executed against the original program, are representative enough to judge semantic equivalence — the paper itself concedes in its threats-to-validity section that translated programs may pass these tests yet deviate on unseen inputs.

What would settle it

Take any translated function TRAVEL reports as correct on its five generated tests, run it on a larger independently authored test suite (or randomized differential testing against the C original), and measure the pass rate; if a substantial fraction fail on inputs outside the original five, the central claim that the pipeline ensures behavior preservation is refuted.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Small models trained with TRAVEL can match or beat proprietary and much larger open models: on xCodeEval a 7B model reaches 71.07% computational accuracy, above the 69.51% reported for GPT-4o.
  • Rule-guided MCTS contributes the largest single gain; ablations show removing reasoning paths drops accuracy on all backbones, e.g., from 68.35% to 67.18% CA on Qwen2.5-Coder-7B.
  • Dual-reward RL is complementary: removing the execution reward lowers accuracy, removing the reasoning reward raises compilation success but lowers accuracy, so the combination balances compilability and semantic correctness.
  • On kernel and industrial functions, TRAVEL raises compilation success rates by roughly 16–18 points absolute and cuts unsafe rates by roughly 13 points, showing the gains transfer beyond benchmark code.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The five test inputs per function are doing far more work than they appear to: they set the training signal, the search reward, and the evaluation metric. A fair test of TRAVEL would re-run the pipeline with an independent, broader test suite; if accuracy collapses on held-out inputs, the semantic-preservation claim is weaker than the headline numbers suggest.
  • Because the reasoning reward is trained on MCTS-derived scores, the reward model can only be as good as the search's terminal tests; this creates a closed loop where test coverage, not model size, is the real ceiling.
  • The same search-plus-dual-reward recipe should transfer to other translation or migration tasks with verifiable outputs — e.g., C++ to Rust or Java to Kotlin — where execution feedback is available but formal equivalence is not.
  • Combining TRAVEL with formal verification tools (like a Rust verifier or translation validation) could convert the test-based guarantee into a proof-based one; the paper's own threat-to-validity section stops at test-based semantic verification.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes TRAVEL, a framework for C-to-Rust translation that combines rule-guided Monte Carlo Tree Search (MCTS) to construct reasoning paths with GRPO-based reinforcement learning using a dual reward: an execution reward based on passing test cases and a reasoning reward from a learned reward model. Experiments are reported on xCodeEval, HW-Bench, and OS-Bench across three backbone LLMs (Qwen2.5-Coder-3B/7B, CodeGemma-7B). TRAVEL consistently outperforms prompting and SFT baselines in computational accuracy (CA), compilation success rate (CSR), and reduced unsafe rate (UR), with ablations attributing gains to the reasoning paths, execution reward, and reasoning reward.

Significance. If the reported improvements are reliable, TRAVEL would be a valuable step toward automated C-to-Rust migration: it combines structured reasoning with RL, is reproducible (code and data are released), and shows consistent gains over multiple stronger baselines and model families. The framework is sensible and the ablations are aligned with the design. However, the paper's central claim of behavioral preservation rests on a weak semantic oracle: only five LLM-generated test inputs per C function are used for training and for the main evaluation, and no uncertainty estimates are provided. These issues undermine the strength of the 'reliable translation' narrative as currently supported, although they are addressable with additional experiments.

major comments (3)
  1. [§2.2.1 / §2.3.1 / §3.5] The only semantic signal for both training and evaluation is a set of five LLM-generated test inputs per C function. These tests determine the MCTS terminal reward (Eq. 2), the execution reward (Eqs. 10–11), and the v_i labels used to train the reasoning reward model (Eq. 5). If the CA numbers in Table 3 are computed with the same five tests (the paper does not state otherwise), then the evaluation is circular and the reported improvements may reflect fitting to the generated tests rather than genuine behavioral equivalence. Section 5.2 concedes that 'translated programs may pass tests yet deviate from the original C code on unseen inputs.' Please (a) state precisely which test cases are used for CA in Table 3; (b) re-evaluate on xCodeEval's official/hidden test cases or on independently generated tests held out from training; and (c) for HW-Bench/OS-Bench, where no behavioral metric is
  2. [Tables 3–5] All reported numbers appear to be from a single run, with no error bars, confidence intervals, or significance tests. Given the stochasticity of GRPO training and even of test-case generation, several headline comparisons are small (e.g., Table 4: 71.07 vs 70.29 CA; Table 3: 87.38 vs 88.74 CSR for the Qwen-7B backbone). The claim of 'consistent improvements' would be much stronger with mean±std over at least three seeds or with bootstrap confidence intervals on the evaluation set. Please add such uncertainty quantification at least for the main results (Tables 3 and 4) and the key ablation rows.
  3. [§2.3.3 / Eq. (12)] The reasoning reward r_reason is a learned regression of the MCTS path value v_i, which itself is derived from execution on the same five generated tests used by r_exec. Thus the two rewards are not independent: r_reason may simply re-encode the execution signal. The ablation 'w/o Reasoning Reward' removes this redundant variable, so its measured contribution (e.g., CA drop of about 0.78 points in Table 4) does not demonstrate independent semantic quality. Please analyze the added value of r_reason beyond r_exec—for example, by training the reward model on held-out path labels or by comparing the rewards' predictions on a separate correctness oracle.
minor comments (5)
  1. [Abstract and §4.1] The abstract reports CA/CSR improvements of 26.22%/18.77% over IRENE, which are averages across three backbone models. Please state this explicitly, as the reader may otherwise compare against the per-model numbers in Table 3. Similarly, the 18.28%/16.51% CSR improvements on HW-Bench/OS-Bench are averages over all baselines, not over a single baseline; clarify the comparator.
  2. [Tables 3 and 5] Several numeric entries appear with missing spaces or merged values, e.g., '68.3587.77', '57.8677.48' in Table 3, and '49.0011.00', '28.049.35' in Table 5. These are unclear and should be corrected.
  3. [Figure 1] The figure contains garbled labels such as '?1, ?2, … ?n' and '① ② ③ ④' that appear as placeholder artifacts. The figure should be cleaned up for the camera-ready version.
  4. [Eq. (14)–(15)] The notation for the execution function is inconsistent (E_xec_k vs E_x∈C_k). Please unify and define the metric carefully, especially whether the test cases are the same as those in Verifiable Components.
  5. [§5.2] The cited support for LLM-generated tests achieving 87.20% line coverage [53] is about code translation performance, not specifically about line coverage from five generated tests. Please provide a direct citation or empirical support for this claim.

Circularity Check

0 steps flagged

No significant circularity: results are execution-based and externally falsifiable; the reasoning reward is an explicitly test-derived training signal, not an independent prediction.

full rationale

TRAVEL's central claim is empirical: it reports CA, CSR, UR, and ULR against baselines on xCodeEval, HW-Bench, and OS-Bench. These metrics are computed by compiling and executing generated Rust code, not by the method's own definitions. The main methodological risk is that Verifiable Components supply only five LLM-generated test inputs per C function (Sec. 2.2.1), and those same tests feed the MCTS terminal reward (Eq. 2), the execution reward (Eqs. 10-11), and the labels v_i used to train the reward model (Eqs. 4-5). The reasoning reward r_reason=f_phi(C,P,R) (Eq. 12) is therefore a learned regressor of the same execution-derived signal, so calling the two rewards 'dual' overstates their independence. However, the paper explicitly defines v_i as the ability of a path to produce translations satisfying the executable test cases, and never presents the reasoning reward as independent ground truth; it is used as a dense training signal, not as the evaluation oracle. Section 5.2 candidly concedes that translated programs may pass tests yet deviate from the original C code on unseen inputs and that the evaluation is test-based semantic verification rather than full formal equivalence. That is a validity/overclaim limitation, not a circular derivation: no equation is defined in terms of the quantity it is used to establish, and the reported gains remain falsifiable by execution on other benchmarks. The self-citations (IRENE [32] as baseline, [17] for ICL setup) are not load-bearing. Therefore no significant circularity is present.

Axiom & Free-Parameter Ledger

5 free parameters · 5 axioms · 0 invented entities

No physical or ontological entities are introduced. The framework's load-bearing choices are: the hand-picked reward weights, five LLM-generated test inputs per function, the maximum MCTS depth, the hand-authored Rust rule library, and the choice of the 32B test-generator model. The key domain assumption is that LLM-generated tests are a sufficient proxy for semantic equivalence, which the paper itself hedges in §5.2.

free parameters (5)
  • Reward weights λ_exec, λ_reason = 0.5, 0.5
    Set in §3.4, combined in Eq. (13); chosen by hand without sensitivity analysis; the balance between execution and reasoning rewards directly shapes the policy.
  • Number of LLM-generated test inputs per function = 5
    Defined in §2.2.1; used for MCTS evaluation and RL execution reward. No ablation; coverage assumption.
  • MCTS maximum reasoning steps per episode = 5
    Hyperparameter in §3.4; bounds search depth.
  • Rust translation rule library = N/A (hand-authored, Table 1)
    The rules guiding MCTS prompts are hand-curated from prior work [12, 32]; completeness not validated and the full set is in the repository.
  • Test-case generator model = Qwen2.5-Coder-32B-Instruct
    Chosen in §2.2.1; all verification signals depend on this model's generated tests.
axioms (5)
  • domain assumption LLM-generated tests adequately validate semantic preservation
    Stated in §2.2.1 and mitigated via line-coverage citation in §5.2; no formal guarantee and the paper admits translations may deviate on unseen inputs.
  • ad hoc to paper The hand-crafted Rust rule library covers the frequent failure modes
    Table 1 lists a few rules; the paper states the complete rules are in the repository, but the sufficiency of these rules is not measured.
  • domain assumption MCTS with LLM step sampling produces coherent reasoning paths
    Selection/expansion/evaluation rely on LLM-generated steps and truncation at first closing tag; malformed intermediate steps can cut a path early.
  • domain assumption Execution results are deterministic and comparable between C and Rust environments
    Eqs. (2) and (10) assume outputs match on identical test inputs; platform/UB differences (e.g., uninitialized memory) are not discussed.
  • standard math Standard RL/GRPO convergence assumptions
    Uses standard PPO-style clipping and unbiased KL estimator from [20]; no new math claimed.

pith-pipeline@v1.3.0-alltime-deepseek · 18814 in / 13616 out tokens · 124887 ms · 2026-08-01T11:09:52.110647+00:00 · methodology

0 comments
read the original abstract

The migration of legacy C programs to Rust has become an important direction for improving software memory safety while alleviating the high cost of manual rewriting. Leveraging large language models (LLMs) for automated C-to-Rust translation has emerged as a promising direction. However, existing LLM-based approaches remain limited. On the one hand, LLMs exhibit limited capability in identifying Rust-specific rules, and inadequate handling of Rust syntax often results in incorrect translations. On the other hand, existing LLMs often struggle to accurately capture the semantics of complex code, resulting in incorrect translations. To address these challenges, we propose a Translation fRAmework Via rule-guided reasoning and rEinforcement Learning, namely TRAVEL, consisting of two modules. The first module employs Monte Carlo Tree Search (MCTS)-based reasoning path construction guided by Rust-specific rules, steering the search toward translation steps that respect the syntactic rules that LLMs frequently violate. The second module introduces reinforcement learning that couples execution feedback with reasoning-quality signals, encouraging the model to construct reasoning paths that accurately capture program semantics, thereby ensuring that the generated Rust code preserves the intended behavior of the original C program. We evaluate TRAVEL on three datasets: xCodeEval (a public benchmark), OS-Bench (functions collected from the Linux kernel), and HW-Bench (an industrial dataset from Huawei). On xCodeEval, TRAVEL outperforms all baselines across three backbone LLMs. In particular, compared to the strongest prompting baseline IRENE, TRAVEL improves computational accuracy (CA) by 26.22% and compilation success rate (CSR) by 18.77%. On HW-Bench and OS-Bench, TRAVEL further improves CSR by 18.28% and 16.51%, respectively, while reducing unsafe rate (UR) by 13.06% and 13.08%, respectively.

Figures

Figures reproduced from arXiv: 2607.19966 by Cuiyun Gao, Feng Luo, Jiachen Liu, Jia Feng, Kui Liu.

Figure 1
Figure 1. Figure 1: Overview of TRAVEL. During MCTS, TRAVEL starts with the initial state as the root and systematically grows the search tree by adding new nodes. Within the context of C-to-Rust translation, we customize the four key operations of the MCTS algorithm as follows: Selection. Starting from the root node 𝑠0, the tree T𝑘 is traversed by repeatedly selecting the child with the highest PUCT score [38] until an unexp… view at source ↗
Figure 2
Figure 2. Figure 2: Application domain distributions of xCodeEval, [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: A case demonstrating that Rule-guided MCTS can [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: A case showing that dual-reward reinforcement [PITH_FULL_IMAGE:figures/full_fig_p010_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

58 extracted references · 1 canonical work pages

  1. [1]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren- cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report.arXiv preprint arXiv:2303.08774 (2023)

    Pith/arXiv arXiv 2023

  2. [2]

    Alexandru Agache, Marc Brooker, Andreea Florescu, Alexandra Iordache, An- thony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa. 2020. Fire- cracker: Lightweight Virtualization for Serverless Applications. In17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20). USENIX Association, 419–434. https://www.usenix.org/conf...

    2020

  3. [3]

    Yash Akhauri, Bryan Lewandowski, Cheng-Hsi Lin, Adrian N Reyes, Grant C Forbes, Arissa Wongpanich, Bangding Yang, Mohamed S Abdelfattah, Sagi Perel, and Xingyou Song. 2025. Performance prediction for large systems via text-to- text regression.arXiv preprint arXiv:2506.21718(2025)

    Pith/arXiv arXiv 2025

  4. [4]

    Anthropic. 2023. Introducing Claude. https://www.anthropic.com/index/ introducing-claude.Anthropic Blog(2023). Accessed: 2026-04-27

    2023

  5. [5]

    Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin...

    2020

  6. [6]

    Yao Cheng, Jianfeng Chen, Jie Chen, Li Chen, Liyu Chen, Wentao Chen, Zhengyu Chen, Shijie Geng, Aoyan Li, Bo Li, Bowen Li, Linyi Li, Boyi Liu, Jerry Liu, Kaibo Liu, Qi Liu, Shukai Liu, Siyao Liu, Tianyi Liu, Tingkai Liu, Yongfei Liu, Rui Long, Jing Mai, Guanghan Ning, Z. Y. Peng, Kai Shen, Jiahao Su, Jing Su, Tao Sun, Yifan Sun, Yunzhe Tao, Guoyin Wang, S...

    Pith/arXiv arXiv doi:10.48550/arxiv.2412.00535 2024

  7. [7]

    Catalin Cimpanu. 2019. Microsoft: 70 percent of all security bugs are memory safety issues. ZDNet. https://www.zdnet.com/article/microsoft-70-percent-of- all-security-bugs-are-memory-safety-issues/

    2019

  8. [8]

    Thomas Claburn. 2023. Microsoft is busy rewriting core Windows library code in memory-safe Rust. The Register. https://www.theregister.com/2023/04/27/ microsoft_windows_rust/

    2023

  9. [9]

    Rémi Coulom. 2006. Efficient selectivity and backup operators in Monte-Carlo tree search. InInternational conference on computers and games. Springer, 72–83

    2006

  10. [10]

    Cybersecurity and Infrastructure Security Agency (CISA). 2023. The Urgent Need for Memory Safety in Software Products. https://www.cisa.gov/news- events/news/urgent-need-memory-safety-software-products. Accessed: 2026- 04-30

    2023

  11. [11]

    Mehmet Emre, Peter Boyland, Aesha Parekh, Ryan Schroeder, Kyle Dewey, and Ben Hardekopf. 2023. Aliasing Limits on Translating C to Safe Rust.Proc. ACM Program. Lang.7, OOPSLA1 (2023), 551–579. doi:10.1145/3586046

    doi:10.1145/3586046 2023

  12. [12]

    Mehmet Emre, Ryan Schroeder, Kyle Dewey, and Ben Hardekopf. 2021. Trans- lating C to safer Rust.Proc. ACM Program. Lang.5, OOPSLA (2021), 1–29. doi:10.1145/3485498

    doi:10.1145/3485498 2021

  13. [13]

    Hasan Ferit Eniser, Hanliang Zhang, Cristina David, Meng Wang, Maria Chris- takis, Brandon Paulsen, Joey Dodds, and Daniel Kroening. 2024. Towards Trans- lating Real-World Code with LLMs: A Study of Translating to Rust.CoRR abs/2405.11514 (2024). arXiv:2405.11514 doi:10.48550/ARXIV.2405.11514

    Pith/arXiv arXiv doi:10.48550/arxiv.2405.11514 2024

  14. [14]

    Wenqi Fan, Yujuan Ding, Liangbo Ning, Shijie Wang, Hengyun Li, Dawei Yin, Tat-Seng Chua, and Qing Li. 2024. A Survey on RAG Meeting LLMs: Towards Retrieval-Augmented Large Language Models. InKDD. ACM, 6491–6501

    2024

  15. [15]

    Muhammad Farrukh, Smeet Shah, Baris Coskun, and Michalis Polychronakis

  16. [16]

    2026.Luo-feng-hitsz/TRA VEL: v1.0.0

    Luo feng hitsz. 2026.Luo-feng-hitsz/TRA VEL: v1.0.0. doi:10.5281/zenodo.21132684

    work page doi:10.5281/zenodo.21132684 2026

  17. [17]

    Shuzheng Gao, Xin-Cheng Wen, Cuiyun Gao, Wenxuan Wang, Hongyu Zhang, and Michael R. Lyu. 2023. What Makes Good In-Context Demonstrations for Code Intelligence Tasks with LLMs?. In38th IEEE/ACM International Conference on Automated Software Engineering, ASE 2023, Luxembourg, September 11-15, 2023. IEEE, 761–773. doi:10.1109/ASE56229.2023.00109

    arXiv 2023

  18. [18]

    Yifei Gao, Chengpeng Wang, Pengxiang Huang, Xuwei Liu, Mingwei Zheng, and Xiangyu Zhang. 2025. Pr2: Peephole raw pointer rewriting with llms for translating c to safer rust.arXiv preprint arXiv:2505.04852(2025)

    Pith/arXiv arXiv 2025

  19. [19]

    Google Project Zero. 2021. Memory Safety and the Prevalence of Ex- ploitable Vulnerabilities. https://googleprojectzero.blogspot.com/2021/02/a-year- of-windows-kernel-exploitation.html. Accessed: 2026-04-30

    2021

  20. [20]

    Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, et al. 2025. DeepSeek-R1 incen- tivizes reasoning in LLMs through reinforcement learning.Nature645, 8081 (2025), 633–638

    2025

  21. [21]

    Jaemin Hong. 2023. Improving Automatic C-to-Rust Translation with Static Analysis. In45th IEEE/ACM International Conference on Software Engineering: ICSE 2023 Companion Proceedings, Melbourne, Australia, May 14-20, 2023. IEEE, 273–277. doi:10.1109/ICSE-COMPANION58688.2023.00074

    arXiv 2023

  22. [22]

    Jaemin Hong and Sukyoung Ryu. 2023. Concrat: An Automatic C-to-Rust Lock API Translator for Concurrent Programs. In45th IEEE/ACM International Confer- ence on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023. IEEE, 716–728. doi:10.1109/ICSE48619.2023.00069

    arXiv 2023

  23. [23]

    Jaemin Hong and Sukyoung Ryu. 2024. To Tag, or Not to Tag: Translating C’s Unions to Rust’s Tagged Unions. InASE. ACM, 40–52

    2024

  24. [24]

    Jaemin Hong and Sukyoung Ryu. 2025. Forcrat: Automatic I/O API Translation from C to Rust via Origin and Capability Analysis. In2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)(Seoul, Korea, Republic of). IEEE Press, 1541–1552. doi:10.1109/ASE63991.2025.00130

    arXiv 2025

  25. [25]

    Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Liang Wang, Weizhu Chen, et al. 2022. Lora: Low-rank adaptation of large language models.Iclr1, 2 (2022), 3

    2022

  26. [26]

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, Kai Dang, Yang Fan, Yichang Zhang, An Yang, Rui Men, Fei Huang, Bo Zheng, Yibo Miao, Shanghaoran Quan, Yunlong Feng, Xingzhang Ren, Xuancheng Ren, Jingren Zhou, and Junyang Lin. 2024. Qwen2.5-Coder Technical Report.arXiv preprint arXiv:240...

    Pith/arXiv arXiv 2024

  27. [27]

    Immunant. 2022. C2Rust. https://github.com/immunant/c2rust

    2022

  28. [28]

    Saiful Bari, Xuan Do Long, Weishi Wang, Md

    Mohammad Abdullah Matin Khan, M. Saiful Bari, Xuan Do Long, Weishi Wang, Md. Rizwan Parvez, and Shafiq Joty. 2024. XCodeEval: An Execution-based Large Scale Multilingual Multitask Benchmark for Code Understanding, Generation, Translation and Retrieval. InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Lon...

    2024

  29. [29]

    Chris Lattner and Vikram S. Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In2nd IEEE / ACM International Symposium on Code Generation and Optimization (CGO 2004), 20-24 March 2004, San Jose, CA, USA. IEEE Computer Society, 75–88. doi:10.1109/CGO.2004.1281665

    Pith/arXiv arXiv 2004

  30. [30]

    Cordy, and Ahmed E

    Michael Ling, Yijun Yu, Haitao Wu, Yuan Wang, James R. Cordy, and Ahmed E. Hassan. 2022. In Rust We Trust - A Transpiler from Unsafe C to Safer Rust. In ICSE-Companion. ACM/IEEE, 354–355

    2022

  31. [31]

    LLVM Project. [n. d.]. Clang: A C Language Family Frontend for LLVM. https: //clang.llvm.org/. Accessed: 2025-05-26

    2025

  32. [32]

    Feng Luo, Kexing Ji, Cuiyun Gao, Shuzheng Gao, Jia Feng, Kui Liu, Xin Xia, and Michael Lyu. 2025. Integrating Rules and Semantics for LLM-Based C-to-Rust Luo et al. Translation. InProceedings of the 41st IEEE International Conference on Software Maintenance and Evolution (ICSME). 685–696. doi:10.1109/ICSME64153.2025. 00069

    arXiv 2025

  33. [33]

    Dakota Mahan, Duy Van Phung, Rafael Rafailov, Chase Blagden, Nathan Lile, Louis Castricato, Jan-Philipp Fränken, Chelsea Finn, and Alon Albalak. 2024. Generative reward models.arXiv preprint arXiv:2410.12832(2024)

    Pith/arXiv arXiv 2024

  34. [34]

    Vikram Nitin, Rahul Krishna, Luiz Lemos do Valle, and Baishakhi Ray. 2025. C2SaferRust: Transforming C Projects into Safer Rust with NeuroSymbolic Tech- niques.CoRRabs/2501.14257 (2025)

    arXiv 2025

  35. [35]

    Vikram Nitin, Rahul Krishna, Luiz Lemos do Valle, and Baishakhi Ray. 2025. C2SaferRust: Transforming C Projects into Safer Rust with NeuroSymbolic Tech- niques.CoRRabs/2501.14257 (2025). arXiv:2501.14257 doi:10.48550/ARXIV.2501. 14257

    doi:10.48550/arxiv.2501.14257 2025

  36. [36]

    OpenAI. 2026. GPT-5.4-mini. https://platform.openai.com. Accessed: 2026-04-30

    2026

  37. [37]

    Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gre- gory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. 2019. PyTorch: An Imperative Style, Hi...

    2019

  38. [38]

    Christopher D Rosin. 2011. Multi-armed bandits with episode context.Annals of Mathematics and Artificial Intelligence61, 3 (2011), 203–230

    2011

  39. [39]

    Rust for Linux. 2024. Nova: a Rust-based GPU Driver. https://rust-for-linux. com/nova-gpu-driver. Accessed: 2025-05-19

    2024

  40. [40]

    Guangming Sheng, Chi Zhang, Zilingfeng Ye, Xibin Wu, Wang Zhang, Ru Zhang, Yanghua Peng, Haibin Lin, and Chuan Wu. 2024. HybridFlow: A Flexible and Efficient RLHF Framework.arXiv preprint arXiv: 2409.19256(2024)

    Pith/arXiv arXiv 2024

  41. [41]

    Seshia, and Koushik Sen

    Manish Shetty, Naman Jain, Adwait Godbole, Sanjit A. Seshia, and Koushik Sen

  42. [42]

    Momoko Shiraishi and Takahiro Shinagawa. 2024. Context-aware Code Seg- mentation for C-to-Rust Translation using Large Language Models.CoRR abs/2409.10506 (2024)

    arXiv 2024

  43. [43]

    David Silver, Aja Huang, Chris J Maddison, Arthur Guez, Laurent Sifre, George Van Den Driessche, Julian Schrittwieser, Ioannis Antonoglou, Veda Panneer- shelvam, Marc Lanctot, et al. 2016. Mastering the game of Go with deep neural networks and tree search.nature529, 7587 (2016), 484–489

    2016

  44. [44]

    David Silver, Julian Schrittwieser, Karen Simonyan, Ioannis Antonoglou, Aja Huang, Arthur Guez, Thomas Hubert, Lucas Baker, Matthew Lai, Adrian Bolton, et al. 2017. Mastering the game of go without human knowledge.nature550, 7676 (2017), 354–359

    2017

  45. [45]

    CodeGemma Team, Heri Zhao, Jeffrey Hui, Joshua Howland, Nam Nguyen, Siqi Zuo, Andrea Hu, Christopher A Choquette-Choo, Jingyue Shen, Joe Kelley, et al. 2024. Codegemma: Open code models based on gemma.arXiv preprint arXiv:2406.11409(2024)

    Pith/arXiv arXiv 2024

  46. [46]

    Torvalds, Linus and Linux kernel contributors. 2026. Linux kernel source tree. https://github.com/torvalds/linux. Accessed: 2026-04-27

    2026

  47. [47]

    Jeffrey Vander Stoep and Stephen Hines. 2022. Memory Safe Languages in Android 13. Google Security Blog. https://security.googleblog.com/2022/12/ memory-safe-languages-in-android-13.html

    2022

  48. [48]

    Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement De- langue, Anthony Moi, Pierric Cistac, Timothee Rault, Remi Louf, Morgan Fun- towicz, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gugger, Mariama Drame, Quentin Lhoest, and Alexander M. Rush. 2020. Transformers: S...

    2020

  49. [49]

    Xiafa Wu and Brian Demsky. 2025. GenC2Rust: Towards Generating Generic Rust Code from C . In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society, Los Alamitos, CA, USA, 90–102. doi:10.1109/ICSE55347.2025.00127

    arXiv 2025

  50. [50]

    An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al. 2025. Qwen3 technical report.arXiv preprint arXiv:2505.09388(2025)

    Pith/arXiv arXiv 2025

  51. [51]

    Aidan ZH Yang, Yoshiki Takashima, Brandon Paulsen, Josiah Dodds, and Daniel Kroening. 2024. Vert: Verified equivalent rust transpilation with large language models as few-shot learners.arXiv preprint arXiv:2404.18852(2024)

    Pith/arXiv arXiv 2024

  52. [52]

    Guang Yang, Yu Zhou, Xiang Chen, Xiangyu Zhang, Terry Yue Zhuo, and Taolue Chen. 2024. Chain-of-Thought in Neural Code Generation: From and for Light- weight Language Models.IEEE Trans. Softw. Eng.50, 9 (Sept. 2024), 2437–2457. doi:10.1109/TSE.2024.3440503

    arXiv 2024

  53. [53]

    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.Proc. ACM Softw. Eng.1, FSE (2024), 1585–1608. doi:10.1145/3660778

    doi:10.1145/3660778 2024

  54. [54]

    Hanliang Zhang, Cristina David, Yijun Yu, and Meng Wang. 2023. Ownership Guided C to Rust Translation. InCA V (3) (Lecture Notes in Computer Science, Vol. 13966). Springer, 459–482

    2023

  55. [55]

    Hanliang Zhang, Cristina David, Yijun Yu, and Meng Wang. 2023. Ownership Guided C to Rust Translation. InComputer Aided Verification - 35th International Conference, CA V 2023, Paris, France, July 17-22, 2023, Proceedings, Part III (Lecture Notes in Computer Science, Vol. 13966), Constantin Enea and Akash Lal (Eds.). Springer, 459–482. doi:10.1007/978-3-0...

    doi:10.1007/978-3-031-37709-9_22 2023

  56. [56]

    Tianyang Zhou, Haowen Lin, Somesh Jha, Mihai Christodorescu, Kirill Levchenko, and Varun Chandrasekaran. 2025. LLM-Driven Multi-step Trans- lation from C to Rust using Static Analysis.CoRRabs/2503.12511 (2025). arXiv:2503.12511 doi:10.48550/ARXIV.2503.12511

    doi:10.48550/arxiv.2503.12511 2025

  57. [2024]

    Syzygy: Dual Code-Test C to (safe) Rust Translation using LLMs and Dynamic Analysis.CoRRabs/2412.14234 (2024)

    Pith/arXiv arXiv 2024

  58. [2025]

    Safetrans: Llm-assisted transpilation from c to rust.arXiv preprint arXiv:2505.10708(2025)

    Pith/arXiv arXiv 2025