Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

His2Trans: A Knowledge-Guided Agentic Framework for Project-Level C-to-Rust Migration

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

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

Pith's one-line read His2Trans claims that reconstructing a compilable Rust skeleton from real build traces before translating function bodies, and reusing accepted C/Rust translation pairs, makes incremental C-to-Rust migration practical in build-complex, part

desk verdict A genuinely useful skeleton-first C-to-Rust migration framework with an honest evaluation, but the self-evolving knowledge base accumulates on compilation success alone and the paper never confronts what that does to semantic correctness. read the letter →

arxiv 2603.02617 v4 pith:R6JVEEGL submitted 2026-03-03 cs.SE

Shengbo Wang , Mingwei Liu , Guangsheng Ou , Yuwen Chen , Zike Li , Yanlin Wang This is my paper
classification cs.SE
keywords C-to-Rustmigrationincrementalcompilationknowledgereusebuildtracesskeleton-firsttranslationcompiler-guidedrepairunsafecodepartiallymigratedecosystems
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

The paper argues that project-level C-to-Rust migration fails because build-critical context is lost when translating files in isolation, and because reusable knowledge from past migrations is ignored. His2Trans addresses both by first reconstructing a compilable project-level Rust skeleton from build traces, with placeholder bodies, and then translating function bodies bottom-up, guided by API-level and fragment-level rules mined from previously accepted C/Rust translation pairs. The framework claims high incremental compilation pass rates, a substantial reduction in unsafe code relative to a rule-based transpiler baseline, and support for mixed C/Rust builds without interface mismatches. If these results hold, automated gradual migration becomes a realistic engineering option for long-lived ecosystems with migration history rather than a function-level toy problem.

What carries the argument

The load-bearing machinery has three parts. (1) Project-Level Skeleton Graph: a typed module-and-dependency graph recovered from build traces (compile commands, preprocessing, symbol extraction); it makes implicit build context explicit as Rust references and compiles with placeholder bodies, turning global build failures into localized repair tasks. (2) Knowledge base of API-Level and Fragment-Level rules: mined from historical C/Rust repositories via file-level and function-level retrieval and reranking, these rules tell the translator which Rust interface to call and which local idiom to use, instead of letting the model invent APIs. (3) Compiler-feedback repair loop with knowledge accumu

What would settle it

Run the translated Rust and original C on the same inputs—through differential fuzzing or property-based testing—and check whether outputs and observable side effects match; if a substantial fraction of compilation-accepted functions diverge on inputs the original handles, the compilation-as-acceptance assumption is false and the knowledge accumulation loop becomes a bug-propagation loop.

Watch

Extended reading notes

Core claim

The central discovery is that 'dependency hell' in project-level C-to-Rust translation can be largely defused by making the build itself the first-class context. Before any function body is generated, His2Trans runs the real build, preprocesses each translation unit under its actual compile flags, and recovers the concrete type definitions, global symbols, signatures, and module dependencies that the compiler would see. These are assembled into a Project-Level Skeleton Graph whose placeholder bodies compile, so every later function translation is a localized insertion into an already valid crate rather than a leap over unknown interfaces. Translation is scheduled bottom-up along the dependen

Load-bearing premise

The framework treats compilation success as the gate for accepting a translated function and feeds accepted pairs back into the knowledge base, so a compiled but behaviorally wrong Rust function becomes a reusable rule that can mislead all later translations.

Editorial extensions

If this is right

  • If the framework's results hold, gradual C-to-Rust migration becomes a build-driven process: first stabilize the skeleton, then fill bodies, rather than a one-shot rewrite.
  • Mixed C/Rust coexistence is supported: translated Rust modules link with untranslated C modules without observed FFI mismatches, and tests that pass fully translated also pass in mixed builds.
  • Historical knowledge reuse substantially reduces repair cost: accumulating accepted pairs cuts average repair rounds on unseen modules by about 60%, making long-lived migration more economical.
  • Cross-domain transfer is partial: on general-purpose benchmarks the framework keeps high compilation feasibility and lowers unsafe code, but functional correctness trails a rule-based transpiler, implying the approach is strongest when the target ecosystem shares migration history with the knowledge base.
  • The unsafe ratio drops significantly (e.g., 24 percentage points relative to a rule-based transpiler on general benchmarks), meaning the output is closer to idiomatic safe Rust.

Reading between the lines

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

  • The acceptance gate is compilation success, not behavioral equivalence; a compiled but semantically divergent function fed back into the knowledge base could propagate a wrong pattern to all later translations. Differential testing or property-based testing on the translated output would be a natural strengthening.
  • The framework's benefit likely scales with the richness of the target ecosystem's migration history; greenfield migrations without historical C/Rust pairs would lose most of the knowledge-reuse advantage and rely on the skeleton and repair loop alone.
  • The reported repair-round reduction suggests the knowledge base acts as a consistency prior as much as a correctness boost; its main value may be in keeping long-lived ecosystems stylistically coherent rather than in unlocking hard semantic cases, which remain at roughly 75% functional correctness on the industrial modules.
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

4 major / 5 minor

Summary. His2Trans is a project-level C-to-Rust migration framework designed for build-complex, partially migrated ecosystems. It first reconstructs a compilable Rust project skeleton from build traces, then translates function bodies bottom-up using LLMs while retrieving API- and fragment-level rules from a knowledge base mined from historical C/Rust migration pairs. Compiler-feedback repair is used iteratively, and successfully compiled translation pairs are accumulated back into the knowledge base. The evaluation reports a 97.51% incremental compilation pass rate on five OpenHarmony modules, mixed C/Rust builds without observed interface mismatches, and, on nine general-purpose benchmarks, 95.74% ICompRate and a reduction in unsafe ratio from 67.93% (C2Rust) to 43.91% (Claude backend), with functional correctness of 58.18%/47.27% depending on the backend. RQ4 reports that accumulated knowledge reduces average repair rounds by about 60% on unseen OpenHarmony modules. The paper's central claim is that skeleton-first translation combined with historical knowledge reuse is an effective, practical strategy for gradual C-to-Rust migration.

Significance. If the full-text results are accurate, the skeleton-first build-trace recovery is a genuinely useful architectural contribution: it addresses the 'dependency hell' problem that blocks project-level translation, and the mixed C/Rust interoperability evidence is a step beyond isolated function-level evaluation. The paper also ships a code link, uses a zero-human-intervention protocol, and includes detailed ablations (RQ3, RQ4) on knowledge and repair effects. However, the semantic-correctness validation is insufficient for the strength of the claims. The knowledge accumulation loop accepts pairs on compilation success alone, but the paper's own functional correctness results show that a large fraction of compiled outputs fail tests. The abstract also reports numbers that do not match Section 4. These issues affect load-bearing claims about 'preserving observable behavior' and require substantive revision.

major comments (4)
  1. [§2.3.4, Algorithm 2 line 12] The knowledge base accumulates a pair as soon as CompileAndInstall returns ok; no test or differential equivalence check is part of this gate. Section 3.3 says acceptance criteria are 'compilation success and downstream project-level test outcomes where available,' but Algorithm 2 never invokes tests. Table 6 shows FC = 58.18% (Claude) and 47.27% (DeepSeek) on general benchmarks, meaning a large fraction of compiled outputs fail tests, yet those outputs are exactly the pairs inserted into K. A wrong-but-compiling translation thus becomes a reusable API/fragment rule for later translations. RQ4's +0.87% ICompRate and -60.69% AvgRepair measure only compilation efficiency, not semantic correctness. The claim that His2Trans preserves observable behavior is therefore unsupported unless accepted pairs are filtered by test/differential equivalence or the claims are reframed.
  2. [Abstract vs. Section 4 (Tables 5-6)] The abstract reports 100.00% ICompRate, 94.92% Test Pass Rate, and 16.35% Unsafe Ratio on 'ten OpenHarmony modules,' and 100%/100%/8.59% on 'eight open-source C projects.' Section 4 reports 97.51% ICompRate, 75% FC, and 37.09% Unsafe on five OpenHarmony modules, and 95.74%/58.18%/43.91% on nine general-purpose benchmarks. Both the numbers and the project counts differ. Since the abstract is the paper's headline evidence, this discrepancy must be resolved before the full-text results can be reliably assessed.
  3. [§2.1, §3.1, §3.2] The KB is mined from OpenHarmony's historical C/Rust migrations, and the principal evaluation of the KB benefit (RQ1, RQ4) is on OpenHarmony modules. Although the evaluated modules are excluded from KB construction, the KB's rules are still drawn from the same ecosystem, so the in-domain tests cannot separate knowledge-reuse benefits from domain overlap. RQ2's cross-domain stress test shows why this matters: FC drops to 58.18%/47.27%, below C2Rust's 94.55%. An out-of-ecosystem industrial evaluation, or an ablation that runs RQ1 with the KB withheld, would isolate the claimed contribution of historical knowledge reuse.
  4. [§4.3, Table 7] In the actual retrieval setting, Pred-Rep achieves ICompRate 82.50% and AvgRepair 1.55, both worse than Base-Rep (90.00%, 1.52); only ground-truth rules improve repair efficiency. Thus the paper's own ablation shows that automatically retrieved rules do not yet provide a clear benefit under the repair loop; the knowledge-reuse advantage is demonstrated mainly with oracle knowledge. The interpretation in §4.3.2 acknowledges this, but the general claim that historical knowledge reuse is effective should be calibrated to the automatically mined KB rather than the ground-truth setting.
minor comments (5)
  1. [Abstract / Table 4] The abstract says 'ten OpenHarmony modules' and 'eight open-source C projects,' while Table 4 lists five industrial modules and nine general-purpose projects. Align the counts and metric names.
  2. [Metrics] Use a single term for the correctness metric: the abstract says 'Test Pass Rate,' while Section 3 defines 'Functional Correctness (FC).' Define both or standardize.
  3. [§4.1.3] The claim that 'every test that passes in the fully translated version also still passes in the mixed version' should include the actual per-module test counts, because the fully translated version of appverify_lite fails before test execution.
  4. [§5 Threats to Validity] The test-suite adequacy threat does not mention the compilation-only acceptance gate. This omission is important given that the knowledge accumulation loop depends on that gate.
  5. [Table 5] His2Trans warning counts on OpenHarmony modules are far higher than C2Rust's (e.g., 315.40 vs. 45.00 for the best configuration). The main text's warning-benefit claim is made only for RQ2, but the contrast should be stated explicitly to avoid overgeneralization.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: historical KB and skeleton construction are independent of the evaluated modules, and functional correctness is reported separately from compilation acceptance.

full rationale

The derivation chain is not circular. The knowledge base is an external artifact mined offline from historical OpenHarmony repositories (Section 2.1), and the RQ1/RQ4 evaluation modules are explicitly excluded from KB construction: the paper states the evaluated tasks 'were strictly excluded from the repositories used for knowledge base construction (Section 2.1) to avoid data leakage' (Section 3.2). Algorithm 2's accumulation step (line 12: 'if ok then K ← AccumulateAcceptedPair') uses only compilation success, but the paper separately defines and reports Functional Correctness via project test suites (Section 3.3) and openly reports FC values well below 100% (75% in RQ1; 47.27% and 58.18% in RQ2, Table 6). Thus compilation acceptance is not renamed as behavioral equivalence. The self-evolving accumulation loop (Section 2.3.4) is aligned with the repair-efficiency metric, but RQ4 measures on separate Group B modules and shows ICompRate and FC essentially unchanged (+0.87% and 0%), so the ~60% AvgRepair reduction is an empirical transfer result, not a forced identity. No self-citations, uniqueness theorems, or ansatz-via-citation chains are load-bearing. The main concerns—domain bias and test-suite adequacy (Section 5) and the unsupported assumption that compilation acceptance approximates semantic equivalence—are validity/threats-to-correctness issues, not circularity.

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

The central claim rests on several hand-chosen hyperparameters (retrieval depth, repair budget, mining thresholds) and on the assumption that compilation success and legacy tests are valid proxies for migration correctness. No new entities are postulated, but the knowledge-base mining pipeline is a domain-specific artifact whose thresholds directly shape the reported results.

free parameters (5)
  • retrieval depth K = 5 (best); swept over {1,3,5,10}
    Controls how many historical translation pairs and rules are injected into the LLM prompt; results vary with K (Table 5), so the headline number depends on this hand-picked hyperparameter.
  • repair budget R = 5
    Maximum number of compile-repair rounds per function (Algorithm 2). If exceeded, falls back to C2Rust unsafe code.
  • BM25 top-20 / file rerank top-5 thresholds = 20/5
    Knowledge-mining pipeline filters candidates to top-20 via BM25 then top-5 via jina-reranker-v3; thresholds are set without ablation.
  • Function-level rerank top-5 = 5
    Only top-5 aligned function pairs per file are used for rule extraction.
  • KB mining heuristics thresholds = 3+ token overlap; >5-char literals; 365-day window
    Table 2 heuristics include hand-chosen thresholds that determine which C/Rust file pairs become 'translation pairs'.
assumptions (4)
  • domain assumption Build-trace preprocessing produces a concrete .i view that fully determines the real build-time declarations (types, macros, symbols).
    Invoked in Section 2.2.2; if the recovered skeleton misses a platform-specific symbol, the whole downstream translation cannot compile.
  • ad hoc to paper Compilation success of a translated Rust function is a sufficient gate for accumulating it into the knowledge base.
    Algorithm 2 line 12; weak because compilation success does not imply semantic equivalence (the paper's own FC numbers show this).
  • domain assumption Project-level test pass rate is a valid measure of functional correctness of the migrated artifact.
    Section 3.3 metrics; test suites are legacy/maintained, and the paper acknowledges test adequacy threats in Section 5.
  • domain assumption The LLM used for generation and repair (DeepSeek-V3.2 / Claude-Opus-4.5) is a sufficiently reliable function-body synthesizer.
    Entire online stage depends on LLM behavior; no formal guarantee.

how reviews work

0 comments
Cite this review

Pith. "Pith review of His2Trans: A Knowledge-Guided Agentic Framework for Project-Level C-to-Rust Migration." pith.science (2026). https://pith.science/paper/R6JVEEGL

@misc{pith2026260302617,
  author       = {Pith},
  title        = {Pith review of: His2Trans: A Knowledge-Guided Agentic Framework for Project-Level C-to-Rust Migration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/R6JVEEGL}},
  note         = {Machine review of arXiv:2603.02617}
}
read the original abstract

C remains a major implementation language for operating systems, embedded platforms, and infrastructure software, but manual memory management continues to create security and maintenance costs. Rust is a practical migration target because it retains low-level control while enforcing stronger memory-safety checks. At project scale, especially under gradual C/Rust coexistence, migration is not a sequence of syntax-preserving function rewrites. A translator must preserve project interfaces, observable behavior, system interaction protocols, and low-level interoperability boundaries while staying consistent with migration choices already made in the codebase. We introduce His2Trans, a knowledge-guided agentic framework for project-level C-to-Rust migration. His2Trans reuses interface-level and fragment-level knowledge mined from historical C/Rust migrations to guide new translations toward Rust interfaces, wrapper choices, and local idioms already accepted in the evolving project. It then refines the assembled crate with project-level agentic feedback. On ten OpenHarmony modules, His2Trans reaches a 100.00\% incremental compilation pass rate, a 94.92\% Test Pass Rate, and a 16.35\% Unsafe Ratio. On eight open-source C projects, it reaches 100.00\% for both incremental compilation and Test Pass Rate, reducing Unsafe Ratio from 42.88\% under C2Rust to 8.59\%. These results support knowledge-guided migration and project-level agentic refinement as practical mechanisms for preserving observable behavior while reducing the unsafe burden of rule-based transpilation.

Figures

Figures reproduced from arXiv: 2603.02617 by the authors.

Figure 1
Figure 1. Overview of the C-to-Rust translation framework. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Workflow of Knowledge Base Construction. The pipeline executes a coarse-to-fine mining process: File-Level Pairing [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Workflow of Incremental Function Translation. The Topological Scheduler dispatches parallel tasks based on the [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Detailed performance metrics for industrial-context modules (RQ1). Darker shades denote better results, “–” indicates [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: A representative definition-gap failure in [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: On buffer, the baseline collapses a struct into an integer handle, which breaks field-level reasoning; our skele￾ton recovers the struct layout, enabling type-correct function bodies. Case Study: Struct Layout Recovery vs. Pointer-as-Integer Collapse [PITH_FULL_IMAGE:…
Figure 7
Figure 7. Figure 7: Comparison of baseline vs. knowledge-guided trans [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Mostly Automatic Translation of Language Interpreters from C to Safe Rust

    cs.PL 2026-06 unverdicted novelty 6.0 of 10

    Reboot translates six C interpreters (6k-23k LOC) to safe Rust with 1-11 interventions each, passing all original tests and 62-92% on new validation tests while removing memory vulnerabilities.

Reference graph

Works this paper leans on

41 extracted references · 1 canonical work pages · cited by 1 Pith paper

  1. [1]

    Android Open Source Project. [n. d.]. Memory safety. https://source.android. com/docs/security/test/memory-safety. Accessed 2026-03-25

    2026

  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. InEngineering of Complex Computer Systems: 29th International Conference, ICECCS 2025, Hangzhou, China, July 2–4, 2025, Proceedings(Hangzhou, Chin...

    work page doi:10.1007/978-3-032-00828-2_16 2025

  3. [3]

    ChromiumOS. [n. d.]. Development Basics. https://www.chromium.org/ chromium-os/developer-library/guides/development/development-basics/. Ac- cessed 2026-03-25

    2026

  4. [4]

    Saman Dehghan, Tianran Sun, Tianxiang Wu, Zihan Li, and Reyhaneh Jab- barvand. 2025. Translating Large-Scale C Repositories to Idiomatic Rust. arXiv:2511.20617 [cs.SE] https://arxiv.org/abs/2511.20617

    arXiv 2025

  5. [5]

    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

  6. [6]

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

    doi:10.1145/3485498 2021

  7. [7]

    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

  8. [8]

    Muhammad Farrukh, Smeet Shah, Baris Coskun, and Michalis Polychron- akis. 2025. SafeTrans: LLM-assisted Transpilation from C to Rust. arXiv:2505.10708 [cs.CR] https://arxiv.org/abs/2505.10708

    arXiv 2025

Show all 41 references
  1. [9]

    Firefox Source Docs. [n. d.]. Rust/C++ interoperability. https://firefox-source- docs.mozilla.org/writing-rust-code/cpp-interop.html. Accessed 2026-03-25

    2026

  2. [10]

    Galois, Inc. 2018. C2Rust. https://galois.com/blog/2018/08/c2rust/. Accessed: 2026-01-27

    2018

  3. [11]

    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

  4. [12]

    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

  5. [13]

    Jaemin Hong and Sukyoung Ryu. 2024. Type-migrating C-to-Rust translation using a large language model.Empirical Software Engineering30 (10 2024). doi:10.1007/s10664-024-10573-2

    2024 doi

  6. [14]

    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

  7. [15]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review.ACM Trans. Softw. Eng. Methodol.33, 8, Article 220 (Dec. 2024), 79 pages. doi...

    2024 doi

  8. [16]

    Ralf Jung, Jacques-Henri Jourdan, Robbert Krebbers, and Derek Dreyer. 2017. RustBelt: securing the foundations of the Rust programming language.Proc. ACM Program. Lang.2, POPL, Article 66 (Dec. 2017), 34 pages. doi:10.1145/3158154

    2017 doi

  9. [17]

    Ralf Jung, Jacques-Henri Jourdan, Robbert Krebbers, and Derek Dreyer. 2021. Safe systems programming in Rust.Commun. ACM64, 4 (March 2021), 144–152. doi:10.1145/3418295

    2021 doi

  10. [18]

    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 Proceedings of the ACM/IEEE 44th international conference on software engineering: companion proceedings. 354–355

    2022

  11. [19]

    Tianyang Liu, Canwen Xu, and Julian McAuley. 2024. RepoBench: Benchmarking Repository-Level Code Auto-Completion Systems. InInternational Conference on Learning Representations, B. Kim, Y. Yue, S. Chaudhuri, K. Fragkiadaki, M. Khan, and Y. Sun (Eds.), Vol. 2024. 47832–47850. h...

    2024

  12. [20]

    Yuchen Liu, Junhao Hu, Yingdi Shan, Ge Li, Yanzhen Zou, Yihong Dong, and Tao Xie. 2025. LLMigrate: Transforming "Lazy" Large Language Models into Efficient Source Code Migrators. arXiv:2503.23791 [cs.PL] https://arxiv.org/abs/2503.23791

    2025 arXiv

  13. [21]

    Feng Luo, Kexing Ji, Cuiyun Gao, Shuzheng Gao, Jia Feng, Kui Liu, Xin Xia, and Michael R. Lyu. 2025. Integrating Rules and Semantics for LLM-Based C-to-Rust Translation. arXiv:2508.06926 [cs.SE] https://arxiv.org/abs/2508.06926

    2025 arXiv

  14. [22]

    Matt Miller. 2019. Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape. Presentation at Blue- Hat IL Conference. https://github.com/microsoft/MSRC-Security- Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20- %20BlueHatIL%20...

    2019

  15. [23]

    Vikram Nitin, Rahul Krishna, Luiz Lemos do Valle, and Baishakhi Ray. 2025. C2SaferRust: Transforming C Projects into Safer Rust with NeuroSymbolic Tech- niques. arXiv:2501.14257 [cs.SE] https://arxiv.org/abs/2501.14257

    2025

  16. [24]

    Vikram Nitin, Rahul Krishna, and Baishakhi Ray. 2025. SpecTra: Enhancing the Code Translation Ability of Language Models by Generating Multi-Modal Specifications. arXiv:2405.18574 [cs.SE] https://arxiv.org/abs/2405.18574

    2025

  17. [25]

    OpenAtom Foundation. [n. d.]. OpenHarmony: A distributed operating system for all scenarios. https://gitee.com/openharmony

  18. [26]

    Baptiste Roziere, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised Translation of Programming Languages. In Advances in Neural Information Processing Systems, H. Larochelle, M. Ran- zato, R. Hadsell, M.F. Balcan, and H. Lin (Eds.), Vol. 33. Curran ...

    2020

  19. [27]

    Momoko Shiraishi, Yinzhi Cao, and Takahiro Shinagawa. 2025. SmartC2Rust: Iterative, Feedback-Driven C-to-Rust Translation via Large Language Models for Safety and Equivalence. arXiv:2409.10506 [cs.SE] doi:10.1145/3744916.3773259

    2025

  20. [28]

    The Chromium Project. 2020. Memory Safety. https://www.chromium.org/ Home/chromium-security/memory-safety/ Accessed: 2026-01-27

    2020

  21. [29]

    The Linux Kernel Documentation. [n. d.]. Quick Start. https://docs.kernel.org/ rust/quick-start.html. Accessed 2026-03-25

    2026

  22. [30]

    Chaofan Wang, Tingrui Yu, Beijun Shen, Jie Wang, Dong Chen, Wenrui Zhang, Yuling Shi, Chen Xie, and Xiaodong Gu. 2026. EvoC2Rust: A Skeleton-guided Framework for Project-Level C-to-Rust Translation. arXiv:2508.04295 [cs.SE] https://arxiv.org/abs/2508.04295

    2026

  23. [31]

    Feng Wang, Yuqing Li, and Han Xiao. 2025. jina-reranker-v3: Last but Not Late Interaction for Listwise Document Reranking. arXiv:2509.25085 [cs.CL] Conference’17, July 2017, Washington, DC, USA Shengbo Wang, Mingwei Liu, Guangsheng Ou, Yuwen Chen, Zike Li, Yanlin Wang, and Zib...

    2025

  24. [32]

    Qingxiao Xu and Jeff Huang. 2025. Optimizing Type Migration for LLM-Based C-to-Rust Translation: A Data Flow Graph Approach. InProceedings of the 14th ACM SIGPLAN International Workshop on the State Of the Art in Program Analysis. 8–14

    2025

  25. [33]

    Aidan Z. H. 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:2404.18852 [cs.PL] https: //arxiv.org/abs/2404.18852

    2024 arXiv

  26. [34]

    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

  27. [35]

    Zhiqiang Yuan, Wenjun Mao, Zhuo Chen, Xiyue Shang, Chong Wang, Yiling Lou, and Xin Peng. 2025. Project-Level C-to-Rust Translation via Synergistic Integra- tion of Knowledge Graphs and Large Language Models. arXiv:2510.10956 [cs.SE] https://arxiv.org/abs/2510.10956

    2025 arXiv

  28. [36]

    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(Paris, France). Springer-Verlag, Berlin, Heide...

    2023 doi

  29. [37]

    Ruxin Zhang, Shanxin Zhang, and Linbo Xie. 2025. A systematic exploration of C-to-rust code translation based on large language models: prompt strategies and automated repair.Automated Software Engineering33 (10 2025). doi:10.1007/ s10515-025-00570-0

    2025

  30. [38]

    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

  31. [39]

    Xu, Zhengbao Jiang, and Graham Neubig

    Shuyan Zhou, Uri Alon, Frank F. Xu, Zhengbao Jiang, and Graham Neubig

  32. [40]

    Tianyang Zhou, Ziyi Zhang, Haowen Lin, Somesh Jha, Mihai Christodorescu, Kirill Levchenko, and Varun Chandrasekaran. 2025. SACTOR: LLM-Driven Correct and Idiomatic C to Rust Translation with Static Analysis and FFI-Based Verification. arXiv:2503.12511 [cs.SE] https://arxiv.org...

    2025

  33. [2023]

    InThe Eleventh International Conference on Learning Representations

    DocPrompting: Generating Code by Retrieving the Docs. InThe Eleventh International Conference on Learning Representations. https://openreview.net/ forum?id=ZTCxT2t2Ru

Pith tools

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