Pith. sign in

REVIEW 3 major objections 6 minor 4 cited by

Syzygy: Dual Code-Test C to (safe) Rust Translation using LLMs and Dynamic Analysis

T0 review · 3 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read Syzygy claims that a 3,000-line C compression library can be translated into safe Rust automatically by pairing LLM code generation with dynamic-analysis-mined specifications and per-function equivalence tests, validated on one million…

desk verdict Solid engineering scale-up with a genuine gap between the headline equivalence claim and the compression-ratio oracle. read the letter →

arxiv 2412.14234 v2 pith:NWKLDWQQ submitted 2024-12-18 cs.SE cs.AIcs.LGcs.PL

Manish Shetty , Naman Jain , Adwait Godbole , Sanjit A. Seshia , Koushik Sen This is my paper · ORCID
classification cs.SEcs.AIcs.LGcs.PL
keywords C-to-RusttranslationsafeRustlargelanguagemodelsdynamicanalysisequivalencetestingrejectionsamplingprogramsynthesisincremental
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

Syzygy claims that C code can be translated to safe Rust automatically at the scale of a whole library by pairing LLM-driven generation with dynamic-analysis-derived information about memory, aliasing, nullability, and function input/output behavior. The approach translates one function (or type) at a time in dependency order, and for each unit it also generates an argument mapper and an equivalence test that compares the Rust behavior against the original C behavior on captured I/O examples. Translation candidates that compile and pass those per-function tests are committed, so each step preserves an invariant that previously translated code still works with the new addition. Applied to a 3,000-line, 98-function C compression library, the pipeline produced a safe-Rust version that passes a one-million-input equivalence suite achieving 95% line and 83% branch coverage; the authors claim this is the largest test-validated automated C-to-safe-Rust translation so far.

What carries the argument

The load-bearing mechanism is iterative aligned translation over a program dependency graph, with a dual code-and-test generation loop. A slicer decomposes the C codebase into functions, structs, typedefs, and macros and topologically sorts them. SpecMiner instruments and executes the C code to mine per-function specifications: types, allocation bounds, nullability, aliasing, and serialized input/output examples. CodeGenerator samples multiple LLM candidate translations, accepting only those that compile under a safe-Rust ban on unsafe blocks. ArgTranslator uses LLM-generated mapping functions plus an argument-construction API to translate C test inputs into Rust objects respecting aliasing and sizes, and EqTester generates equivalence tests that execute both versions and compare outputs. Rejection sampling at each stage filters candidates, and failing equivalence tests provide diff-based feedback for multi-round repair.

What would settle it

Take the translated and original C compression library and run a differential test that compares the exact compressed byte streams, or the decompressed outputs, on a large corpus of inputs sampled from the same length distribution. Any input for which the byte streams differ while the compression ratios match would show that the ratio-based oracle missed a behavioral difference; likewise, any crash the Rust version exhibits on inputs inside the tested range would do so.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central discovery is that the bottleneck in C-to-Rust translation is not the LLM's ability to write plausible code but the ability to know what the C code does at runtime and to test each piece in isolation. Syzygy mines execution traces of the top-level entry point to recover allocation sizes, pointer types, nullability, aliasing relations, and serialized I/O examples for every internal function; these specifications guide the LLM's signature choices and make possible reliable per-function equivalence tests. By looping over the dependency graph, translating bottom-up while generating both code and tests, the method filters out incorrect translations with execution feedback and repairs them with diff-based error messages. The result is a safe-Rust translation of the full library, validated end-to-end on one million compression tests; the paper claims this is the largest test-validated automated C-to-safe-Rust translation achieved so far.

Load-bearing premise

The load-bearing premise is that comparing compression ratios on the tested inputs is an adequate check of functional equivalence; if two implementations compress to the same ratio while producing different outputs, the validation suite would not catch the divergence.

Editorial extensions

If this is right

  • Whole-library translation becomes tractable because the per-function equivalence invariant catches an error in one unit before dependent units are built, which is how the pipeline reaches 98 functions.
  • LLM output alone is not enough: without intermediate testing the pipeline still produces a compiling translation, but the ablation shows it crashes on trivial inputs, implying execution filtering is what makes the result usable.
  • Safe Rust can be produced end-to-end for a real library, but with a performance cost: optimized Rust is up to 3.67x slower than optimized C, largely from Vec allocations and bounds checks.
  • The approach carries practical constraints, including manual struct definitions and a current scope limited to acyclic data structures, single-threaded code, and no type punning.

Reading between the lines

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

  • Beyond the paper's claims: the ratio-based equivalence oracle could be upgraded to exact-output differential testing, which would turn the million-test pass from a compression-equality claim into an exact behavioral-equivalence claim for those inputs.
  • Beyond the paper's claims: the same recipe of fuzzing a documented entry point, mining internal function I/O, and letting equivalence tests drive incremental LLM translation could transfer to other C libraries, though cost and sampling rates remain open questions.
  • Beyond the paper's claims: because the paper reports that compiling alone leaves a long tail of functions with pass rates below 20%, a testable extension is to measure whether increased sampling or stronger dynamic analyses specifically rescue that tail.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper presents Syzygy, an LLM-driven pipeline that translates C codebases to safe Rust by decomposing the code into dependency-ordered translation units, mining dynamic specifications (types, bounds, nullability, aliasing, I/O examples) from instrumented C executions, and generating both Rust code and per-function equivalence tests whose expected outputs are obtained by translating real C I/O through LLM-generated translateArgs functions. The pipeline uses rejection sampling, compilation filtering, and test-failure feedback with multi-round repair. The main evaluation translates Zopfli, a compression library of roughly 3,000 lines and 98 functions, into safe Rust, and validates the result with a top-level suite of one million inputs. The paper claims this is the largest automated, test-validated C-to-safe-Rust translation to date.

Significance. If the translation is actually behaviorally equivalent on the tested inputs, this is a significant engineering and empirical contribution: it demonstrates a scalable recipe that combines dynamic analysis, LLM sampling, and incremental test-based equivalence checks, and it provides an ablation showing that test feedback is needed to go from merely compiling code to runnable code. The per-function EqTester design, which checks exact value equivalence against real C executions, is a genuine strength, as is the transparent reporting of cost, repair, and coverage. The central weakness is that the million-input top-level validation only compares compression ratios, not compressed byte streams, so the paper's headline equivalence claim is not supported by that suite. This issue is load-bearing and needs to be resolved before the main claim can be accepted.

major comments (3)
  1. [Section 6.2.2] The sentence "We use these to check equivalence in compression ratios between the C and Rust programs" defines the oracle for the one-million-input validation. Since the same input is compressed by both programs, compression-ratio equality is exactly compressed-length equality; two different DEFLATE streams of equal length would both pass. This does not establish the observational equivalence P_C(t) ≃ P_R(t) required by Section 3, and it does not justify the abstract's phrase "test-validated equivalence." Please either compare exact compressed byte arrays and report how many inputs differ, or explicitly restrict the validation claim to compression-ratio equivalence and adjust the problem statement and abstract accordingly.
  2. [Sections 4.3.1, 6.2.1, 6.2.2] The end-to-end pipeline is not fully automated as claimed. The paper reports manual specification of Rust structs (Section 4.3.1), manual verification of non-function translation units such as structs, globals, and macros (Section 6.2.1), and a manually strategized repair of zopfli_block_split_lz77 (Section 6.2.2). The exact per-function EqTester evidence is also seeded by only 26 top-level inputs (Section 6.2.1). The paper should state clearly which steps are automated and which require human intervention, and should quantify how many per-function I/O examples and exact equivalence tests were actually used, so that the "largest automated and test-validated" claim can be assessed accurately.
  3. [Sections 4.4.1, 4.4.3, 5.4, 5.5] The test oracle itself is LLM-generated: translateArgs maps C inputs and expected outputs to Rust objects, and the equivalence test is generated by the LLM. If translateArgs or the generated assertions are incorrect, the commutative diagram in Section 4.4.3 can pass vacuously even when the Rust function is not equivalent. The paper transfers soundness to test reliability, but it provides no independent validation of translateArgs or of the generated assertions. Please add a concrete check, such as hand-validating translateArgs on a sample of per-function tests, reporting the number of failing per-function tests and repair rounds, or comparing against a mechanically constructed oracle for at least the 26 top-level inputs.
minor comments (6)
  1. [Figure 6 caption] The caption says "the a argument in sum points to a single int while that in sum points to an array of ints"; the second mention of sum should likely be square, since square modifies a single int and sum iterates over an array.
  2. [Table 3] The table reports execution times without units; please state that the numbers are seconds (or another explicit unit).
  3. [Section 6.2.4] The text says GPT-4O can "generate a correct translation for Zopfli" but immediately adds that the translation "crashes on some long test inputs"; a translation that crashes on tests is not a correct translation, so this wording should be revised.
  4. [Figure 7] The sampling diagram reuses K for both the translateArgs and EqTester sampling stages without defining it; please define K once or use distinct symbols.
  5. [Section 6.2.2] The test-input description "ranging between 1e1 and 1e7 characters" should use explicit notation such as 10 to 10^7 characters for clarity.
  6. [Section 8.2] The phrase "generated over 1000000 tests" should be "generate over 1,000,000 tests" for readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the C source is the external specification and the validation compares the generated Rust code against C behavior.

full rationale

Syzygy's central claim is an empirical translation result: a C program is the specification, and the generated Rust code is validated by differential testing against the original C program. The per-function EqTester executes the actual C function, serializes its inputs/outputs, translates those C values to Rust via the LLM-generated translateArgs, and asserts value-based equality with the Rust function's outputs. The final 1M-input Zopfli suite also runs both the C and Rust programs and compares compression ratios. Nothing in this chain defines the target result in terms of itself: the Rust code is not used to construct the expected C outputs, and no fitted parameter is renamed as a prediction. The paper's self-citations (e.g., R2E, LiveCodeBench) appear only in related-work discussions and are not load-bearing for the translation claim; no uniqueness theorem or prior-work assumption is invoked to force the approach. The same LLM family generating both code and tests could create a shared-blind-spot reliability concern, and the Section 6.2.2 compression-ratio check is weaker than the Section 3 output-equivalence definition, since two different DEFLATE streams of equal length would both yield the same ratio. However, these are threats to validity and test-oracle strength, not circular reductions: the paper explicitly acknowledges test-based equivalence is incomplete in Section 8.2. No quoted step exhibits an Eq X = Eq Y reduction by construction, so there is no significant circularity.

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

The central claim rests on domain restrictions for the input C code, the fidelity of dynamic analysis, the correctness of LLM-generated test infrastructure, and the adequacy of compression-ratio equivalence as a validation oracle. No numeric model parameters are fitted; the main free choices are undocumented sampling budgets and hand-picked test corpora.

free parameters (1)
  • LLM sampling budgets (N, M, S in Fig. 7) = not reported
    The pipeline samples N candidate Rust functions, M translateArgs functions, and S equivalence tests per unit, but exact budgets are not reported. Results, cost, and pass rates depend on these hand-chosen values.
assumptions (4)
  • domain assumption The C codebase satisfies the declared restrictions: acyclic data structures, no multithreading, no type punning (Section 3).
    The translation and dynamic analyses assume these restrictions; Zopfli is selected because it agrees with them, so the result does not generalize to cyclic, multithreaded, or type-punning code.
  • domain assumption Dynamic instrumentation faithfully recovers allocation sizes, aliasing, and nullability for all relevant executions (Section 4.2).
    SpecMiner's LLVM pass plus runtime tracks allocations and argument properties; if an execution path is not exercised by the 26 training inputs, inferred properties can be wrong and lead to an incorrect Rust signature.
  • domain assumption The LLM-generated translateArgs and eqtest functions correctly map C I/O to Rust and enforce the intended comparison (Section 4.4).
    Equivalence tests are themselves LLM artifacts; a bug in argument translation can make bad Rust translations pass. The paper provides examples but no systematic audit of test correctness.
  • ad hoc to paper Compression-ratio equality is an acceptable equivalence oracle for top-level validation (Section 6.2.2).
    The 1M-test validation compares compression ratios rather than exact compressed output, so bitstreams that differ but have the same length would satisfy the oracle. This is the weakest epistemic premise and does not follow from the problem formulation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Syzygy: Dual Code-Test C to (safe) Rust Translation using LLMs and Dynamic Analysis." pith.science (2026). https://pith.science/paper/NWKLDWQQ

@misc{pith2026241214234,
  author       = {Pith},
  title        = {Pith review of: Syzygy: Dual Code-Test C to (safe) Rust Translation using LLMs and Dynamic Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NWKLDWQQ}},
  note         = {Machine review of arXiv:2412.14234}
}
read the original abstract

Despite extensive usage in high-performance, low-level systems programming applications, C is susceptible to vulnerabilities due to manual memory management and unsafe pointer operations. Rust, a modern systems programming language, offers a compelling alternative. Its unique ownership model and type system ensure memory safety without sacrificing performance. In this paper, we present Syzygy, an automated approach to translate C to safe Rust. Our technique uses a synergistic combination of LLM-driven code and test translation guided by dynamic-analysis-generated execution information. This paired translation runs incrementally in a loop over the program in dependency order of the code elements while maintaining per-step correctness. Our approach exposes novel insights on combining the strengths of LLMs and dynamic analysis in the context of scaling and combining code generation with testing. We apply our approach to successfully translate Zopfli, a high-performance compression library with ~3000 lines of code and 98 functions. We validate the translation by testing equivalence with the source C program on a set of inputs. To our knowledge, this is the largest automated and test-validated C to safe Rust code translation achieved so far.

Figures

Figures reproduced from arXiv: 2412.14234 by the authors.

Figure 1
Figure 1. Overview of our Syzygy translation approach: Slicer decomposes the codebase into translation units, CodeGenerator performs translation for that unit, and EqTester checks for equivalence of the generated Rust code with the original C code. ArgTranslator maps the C and Rust function arguments allowing appropriate equivalence checks in EqTester. SpecMiner, our dynamic analysis module mines (property and I/O) specificat… view at source ↗
Figure 2
Figure 2. Translation Pipeline for a C function f: Given a C function and tests for the C codebase, first, the SpecMiner uses dynamic analysis to mine input-output (I/O) and property specifications for the translation. These properties (e.g., nullability and aliasing) guide a CodeGenerator to generate a candidate Rust translation of f. Given the translated signature and the collected C I/O, the ArgTranslator generates an tran… view at source ↗
Figure 3
Figure 3. Dynamic Specification Mining: An example C code snippet which features dynamic allocations (in caller1 and caller2), function pointers (in f), aliasing between arguments (in the main – caller2 – f call chain). While this information can greatly assist CodeGenerator and EqTester, inferring it statically is challenging. We use a combination of dynamic analyses (see §4.2.1). a conservative approach for void pointers, m… view at source ↗
Figures from the paper (13 more)
Figure 4
Figure 4. Figure 4: Struct field choices induce function signatures higher in the call chain. Left: C struct [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Nullability information guides Rust function signature. The arguments bp, out, outsize of EncodeTree function can be NULL. However, the LLM cannot infer these properties from function context and generates an incorrect signature without Option, failing equivalence. Pro…
Figure 6
Figure 6. Figure 6: Challenges with mapping function arguments from C to Rust: both [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 7
Figure 7. Figure 7: Illustration of the rejection sampling approach used to translate a C function [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]
Figure 8
Figure 8. Figure 8: We discovered some runtime exceptions when running our equivalence test suite. We used our [PITH_FULL_IMAGE:figures/full_fig_p017_8.png]
Figure 9
Figure 9. Figure 9: Box plot demonstrating pass rates for Code Compilation and Test Execution. We measure the per-function pass rates for compilation and test execution. Note that for test execution, we use the compiling solutions as the set of submitted solutions (denominator when comput…
Figure 10
Figure 10. Figure 10: Rust Code Generation Prompt [PITH_FULL_IMAGE:figures/full_fig_p028_10.png]
Figure 11
Figure 11. Figure 11: TranslateArgs Prompt [PITH_FULL_IMAGE:figures/full_fig_p029_11.png]
Figure 12
Figure 12. Figure 12: Rust Equivalence Test Generation Prompt [PITH_FULL_IMAGE:figures/full_fig_p030_12.png]
Figure 13
Figure 13. Figure 13: The GetCostModelMinCost function from the Zopfli codebase. The function’s complexity stems from using indirect function calls through the costmodel function pointer coupled with a void∗ context parameter. Particularly hard is to interpret (purely statically) that the …
Figure 14
Figure 14. Figure 14: A candidate Rust translation generated for the C function [PITH_FULL_IMAGE:figures/full_fig_p032_14.png]
Figure 15
Figure 15. Figure 15: The LLM generated translateArgs function for the GetCostModelMinCost, handling the translation of C function pointers to Rust closures, supporting multiple variants the pointer may point to: GetCostFixed and GetCostStat. The translateArgs is aligned with the candidate…
Figure 16
Figure 16. Figure 16: The LLM generated equivalence test for the C function GetCostModelMinCost ( [PITH_FULL_IMAGE:figures/full_fig_p034_16.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 4 Pith papers

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

  1. MigrationBench: Repository-Level Code Migration Benchmark from Java 8

    cs.SE 2025-05 conditional novelty 7.0 of 10

    MigrationBench provides 5,102 real Maven repositories as a Java 8 to Java 17 migration benchmark, plus an evaluation framework and an LLM feedback agent that achieves 62.33% minimal and 27.33% maximal migration succes...

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

    cs.SE 2026-07 conditional novelty 6.0 of 10

    A rule-guided MCTS plus dual-reward reinforcement learning pipeline improves LLM-based C-to-Rust translation accuracy and cuts unsafe Rust output across three benchmarks.

  3. MatchFixAgent: Language-Agnostic Autonomous Repository-Level Code Translation Validation and Repair

    cs.SE 2025-09 conditional novelty 6.0 of 10

    A lightweight multi-agent LLM framework validates and repairs cross-language code translations with verdicts on 99.2% of 2,219 translation pairs and repairs 50.6% of detected bugs.

  4. Vibration-Based Energy Metric for Restoring Needle Alignment in Autonomous Robotic Ultrasound

    cs.RO 2025-08 unverdicted novelty 6.0 of 10

    A vibration-based energy metric, obtained by periodically vibrating the needle, is used as an out-of-plane feedback signal to re-align the ultrasound probe with the needle plane, reporting 0.41 mm translation and 0.51...

Reference graph

Works this paper leans on

61 extracted references · 24 canonical work pages · cited by 4 Pith papers

  1. [1]

    Aws Albarghouthi, Sumit Gulwani, and Zachary Kincaid. 2013. Recursive program synthesis. In Computer Aided Verification: 25th International Conference, CA V 2013, Saint Petersburg, Russia, July 13-19, 2013. Proceedings 25 . Springer, 934–950

    work page 2013

  2. [2]

    Rajeev Alur, Rastislav Bodik, Garvit Juniwal, Milo M. K. Martin, Mukund Raghothaman, Sanjit A. Seshia, Rishabh Singh, Armando Solar-Lezama, Emina Torlak, and Abhishek Udupa. 2013. Syntax-guided synthesis. In 2013 Formal Methods in Computer-Aided Design . 1–8. https://doi.org/10.1109/FMCAD.2013.6679385

    arXiv 2013

  3. [3]

    Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, B Ashok, and Shashank Shet. 2024. Codeplan: Repository-level coding using llms and planning. Proceedings of the ACM on Software Engineering 1, FSE (2024), 675–698

    2024

  4. [4]

    Thomas Ball. 1999. The concept of dynamic analysis. SIGSOFT Softw. Eng. Notes 24, 6 (Oct. 1999), 216–234. https: //doi.org/10.1145/318774.318944

    arXiv 1999

  5. [5]

    Bradley Brown, Jordan Juravsky, Ryan Ehrlich, Ronald Clark, Quoc V Le, Christopher Ré, and Azalia Mirhoseini. 2024. Large language monkeys: Scaling inference compute with repeated sampling. arXiv preprint arXiv:2407.21787 (2024)

    arXiv 2024

  6. [6]

    Pedro Calais and Lissa Franzini. 2023. Test-Driven Development Benefits Beyond Design Quality: Flow State and Developer Experience. In2023 IEEE/ACM 45th International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER). IEEE, 106–111

    work page 2023

  7. [7]

    carol-10-cents. 2024. rust-out-your-c. https://github.com/carols10cents/rust-out-your-c-talk

    work page 2024

  8. [8]

    Federico Cassano, John Gouwar, Francesca Lucchetti, Claire Schlesinger, Anders Freeman, Carolyn Jane Anderson, Molly Q Feldman, Michael Greenberg, Abhinav Jangda, and Arjun Guha. 2024. Knowledge transfer from high-resource to low-resource programming languages for code llms.Proceedings of the ACM on Programming Languages 8, OOPSLA2 (2024), 677–708

    work page 2024

Show all 61 references
  1. [9]

    Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin, Jian-Guang Lou, and Weizhu Chen. 2022. Codet: Code generation with generated tests. arXiv preprint arXiv:2207.10397 (2022)

    2022 arXiv

  2. [10]

    Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. 2023. Teaching large language models to self-debug. arXiv preprint arXiv:2304.05128 (2023)

    2023 arXiv

  3. [11]

    Mehul Damani, Idan Shenfeld, Andi Peng, Andreea Bobu, and Jacob Andreas. 2024. Learning How Hard to Think: Input-Adaptive Allocation of LM Computation. arXiv preprint arXiv:2410.04707 (2024)

    2024 arXiv

  4. [12]

    DARPA. 2024. TRACTOR: Translating All C to Rust. https://www.darpa.mil/research/programs/translating-all-c-to-rust

    2024

  5. [13]

    Hasan Ferit Eniser, Hanliang Zhang, Cristina David, Meng Wang, Maria Christakis, Brandon Paulsen, Joey Dodds, and Daniel Kroening. 2024. Towards translating real-world code with llms: A study of translating to rust. arXiv preprint arXiv:2405.11514 (2024)

    2024 arXiv

  6. [14]

    Galois Inc. 2024. Function Argument Nullability Using an LLM . https://galois.com/blog/2024/11/function-argument- nullability-using-an-llm/

    2024

  7. [15]

    google. 2024. google/zopfli. https://github.com/google/zopfli/

    2024

  8. [16]

    Ali Reza Ibrahimzada, Kaiyao Ke, Mrigank Pawagi, Muhammad Salman Abid, Rangeet Pan, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. Repository-Level Compositional Code Translation and Validation. arXiv preprint arXiv: 2410.24117 (2024)

    2024 arXiv

  9. [17]

    Immunant Inc. 2020. immunant/c2rust. https://github.com/immunant/c2rust

    2020

  10. [18]

    Immunant Inc. 2024. Emitting Safer Rust with C2Rust . https://immunant.com/blog/2023/03/lifting/

    2024

  11. [19]

    Jeevana Priya Inala, Chenglong Wang, Mei Yang, Andres Codas, Mark Encarnación, Shuvendu Lahiri, Madanlal Musuvathi, and Jianfeng Gao. 2022. Fault-aware neural code rankers. Advances in Neural Information Processing Systems 35 (2022), 13419–13432

    2022

  12. [20]

    Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. 2024. Livecodebench: Holistic and contamination free evaluation of large language models for code. arXiv preprint arXiv:2403.07974 (2024)

    2024 arXiv

  13. [21]

    Naman Jain, Manish Shetty, Tianjun Zhang, King Han, Koushik Sen, and Ion Stoica. 2024. R2E: Turning any Github Repository into a Programming Agent Environment. In Forty-first International Conference on Machine Learning

    2024

  14. [22]

    Naman Jain, Skanda Vaidyanath, Arun Iyer, Nagarajan Natarajan, Suresh Parthasarathy, Sriram Rajamani, and Rahul Sharma. [n.d.]. Jigsaw: Large Language Models meet Program Synthesis. In ICSE 2022 (Pittsburgh, Pennsylvania)

    2022

  15. [23]

    Naman Jain, Tianjun Zhang, Wei-Lin Chiang, Joseph E Gonzalez, Koushik Sen, and Ion Stoica. 2023. Llm-assisted code cleaning for training accurate code generators. arXiv preprint arXiv:2311.14904 (2023)

    2023 arXiv

  16. [24]

    Prithwish Jana, Piyush Jha, Haoyang Ju, Gautham Kishore, Aryan Mahajan, and Vijay Ganesh. 2023. Attention, Compilation, and Solver-based Symbolic Analysis are All You Need. arXiv preprint arXiv:2306.06755 (2023)

    2023 arXiv

  17. [25]

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2024. A Survey on Large Language Models for Code Generation. arXiv preprint arXiv:2406.00515 (2024). Syzygy: Dual Code-Test C to (safe) Rust Translation using LLMs and Dynamic Analysis 25

    2024 arXiv

  18. [26]

    Mingsheng Jiao, Tingrui Yu, Xuan Li, Guanjie Qiu, Xiaodong Gu, and Beijun Shen. 2023. On the Evaluation of Neural Code Translation: Taxonomy and Benchmark. In Automated Software Engineering (ASE) . IEEE, 1529–1541. https://doi.org/10.1109/ASE56229.2023.00114

    2023

  19. [27]

    Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-world Github Issues?. In The Twelfth International Conference on Learning Representations. https://openreview.net/forum...

    2024

  20. [28]

    jwerle. 2024. jwerle/url. https://github.com/jwerle/

    2024

  21. [29]

    Chris Lattner and Vikram Adve. 2004. LLVM: A compilation framework for lifelong program analysis & transformation. In International symposium on code generation and optimization, 2004. CGO 2004. IEEE, 75–86

    2004

  22. [30]

    Hongyu Li, Liwei Guo, Yexuan Yang, Shangguang Wang, and Mengwei Xu. 2024. An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise. In 2024 USENIX Annual Technical Conference (USENIX ATC 24). USENIX Association, Santa Clara, CA, 425–443. https://www.u...

    2024

  23. [31]

    Ruishi Li, Bo Wang, Tianyu Li, Prateek Saxena, and Ashish Kundu. 2024. Translating C To Rust: Lessons from a User Study. arXiv preprint arXiv:2411.14174 (2024)

    2024 arXiv

  24. [32]

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. 2022. Competition-level code generation with alphacode. Science 378, 6624 (2022), 1092–1097

    2022

  25. [33]

    Junwei Liu, Kaixin Wang, Yixuan Chen, Xin Peng, Zhenpeng Chen, Lingming Zhang, and Yiling Lou. 2024. Large language model-based agents for software engineering: A survey. arXiv preprint arXiv:2409.02977 (2024)

    2024 arXiv

  26. [34]

    Zohar Manna and Richard Waldinger. 1980. A Deductive Approach to Program Synthesis. ACM Trans. Program. Lang. Syst. 2, 1 (Jan. 1980), 90–121. https://doi.org/10.1145/357084.357090

    1980

  27. [35]

    Nachiappan Nagappan, E Michael Maximilien, Thirumalesh Bhat, and Laurie Williams. 2008. Realizing quality improvement through test driven development: results and experiences of four industrial teams. Empirical Software Engineering 13 (2008), 289–302

    2008

  28. [36]

    Michael L. Nelson. 2005. A Survey of Reverse Engineering and Program Comprehension. arXiv preprint (2005)

    2005

  29. [37]

    Ansong Ni, Srini Iyer, Dragomir Radev, Veselin Stoyanov, Wen-tau Yih, Sida Wang, and Xi Victoria Lin. 2023. Lever: Learning to verify language-to-code generation with execution. In International Conference on Machine Learning . PMLR, 26106–26128

    2023

  30. [38]

    Theo X Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar-Lezama. 2023. Is Self-Repair a Silver Bullet for Code Generation?. In The Twelfth International Conference on Learning Representations

    2023

  31. [39]

    OpenBSD Project. n.d.. unifdef: remove preprocessor conditionals from code . https://man.openbsd.org/unifdef https: //man.openbsd.org/unifdef

  32. [40]

    Baptiste Rozière, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised Translation of Programming Languages. In NeurIPS

    2020

  33. [41]

    Baptiste Rozière, Jie Zhang, François Charton, Mark Harman, Gabriel Synnaeve, and Guillaume Lample. 2022. Lever- aging Automated Unit Tests for Unsupervised Code Translation. In ICLR. OpenReview.net

    2022

  34. [42]

    Quan Shi, Michael Tang, Karthik Narasimhan, and Shunyu Yao. 2024. Can Language Models Solve Olympiad Programming? arXiv:2404.10952 [cs.CL]

    2024 arXiv

  35. [43]

    Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2024. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems 36 (2024)

    2024

  36. [44]

    Momoko Shiraishi and Takahiro Shinagawa. 2024. Context-aware Code Segmentation for C-to-Rust Translation using Large Language Models. arXiv preprint arXiv: 2409.10506 (2024)

    2024

  37. [45]

    Charlie Snell, Jaehoon Lee, Kelvin Xu, and Aviral Kumar. 2024. Scaling llm test-time compute optimally can be more effective than scaling model parameters. arXiv preprint arXiv:2408.03314 (2024)

    2024 arXiv

  38. [46]

    Marc Szafraniec, Baptiste Roziere, Hugh Leather Francois Charton, Patrick Labatut, and Gabriel Synnaeve. 2023. Code translation with Compiler Representations. ICLR (2023)

    2023

  39. [47]

    László Szekeres, Mathias Payer, Tao Wei, and Dawn Song. 2013. SoK: Eternal War in Memory. In2013 IEEE Symposium on Security and Privacy . 48–62. https://doi.org/10.1109/SP.2013.13

    2013 doi

  40. [48]

    Zilu Tang, Mayank Agarwal, Alexander Shypula, Bailin Wang, Derry Wijaya, Jie Chen, and Yoon Kim. 2023. Explain- then-translate: an analysis on improving program translation with self-generated explanations. In Findings of the Association for Computational Linguistics: EMNLP 20...

    2023 doi

  41. [49]

    Sindhu Tipirneni, Ming Zhu, and Chandan K. Reddy. 2024. StructCoder: Structure-Aware Transformer for Code Generation. ACM Trans. Knowl. Discov. Data 18, 3, Article 70 (Jan. 2024), 20 pages. https://doi.org/10.1145/3636430

    2024 doi

  42. [50]

    Evan Wang, Federico Cassano, Catherine Wu, Yunfeng Bai, Will Song, Vaskar Nath, Ziwen Han, Sean Hendryx, Summer Yue, and Hugh Zhang. 2024. Planning In Natural Language Improves LLM Search For Code Generation. arXiv preprint arXiv: 2409.03733 (2024). 26 M. Shetty, N. Jain, A. G...

    2024 arXiv

  43. [51]

    Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H

    Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brenna...

    2024 arXiv

  44. [52]

    Yangzhen Wu, Zhiqing Sun, Shanda Li, Sean Welleck, and Yiming Yang. 2024. Inference scaling laws: An empirical analysis of compute-optimal inference for problem-solving with language models. arXiv preprint arXiv:2408.00724 (2024)

    2024 arXiv

  45. [53]

    Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2024. Agentless: Demystifying LLM-based Software Engineering Agents. arXiv preprint (2024)

    2024

  46. [54]

    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 preprint arXiv: 2404.18852 (2024)

    2024 arXiv

  47. [55]

    John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. arXiv preprint arXiv:2405.15793 (2024)

    2024 arXiv

  48. [56]

    Nguyen, Shaohua Wang, and Xiaohu Yang

    Xin Yin, Chao Ni, Tien N. Nguyen, Shaohua Wang, and Xiaohu Yang. 2024. Rectifier: Code Translation with Corrector via LLMs. CoRR abs/2407.07472 (2024). https://doi.org/10.48550/ARXIV.2407.07472 arXiv:2407.07472

    2024 doi arXiv

  49. [57]

    Eric Zelikman, Qian Huang, Gabriel Poesia, Noah D Goodman, and Nick Haber. 2022. Parsel : Algorithmic Reasoning with Language Models by Composing Decompositions. https://arxiv.org/abs/2212.10561

    2022 arXiv

  50. [58]

    Hanliang Zhang, Cristina David, Meng Wang, Brandon Paulsen, and Daniel Kroening. 2024. Scalable, Validated Code Translation of Entire Projects using Large Language Models. arXiv preprint arXiv:2412.08035 (2024)

    2024 arXiv

  51. [59]

    David, Y

    HanLiang Zhang, C. David, Y. Yu, and M. Wang. 2023. Ownership guided C to Rust translation.International Conference on Computer Aided Verification (2023). https://doi.org/10.48550/arXiv.2303.10515

    2023 doi arXiv

  52. [60]

    Kexun Zhang, Shang Zhou, Danqing Wang, William Yang Wang, and Lei Li. 2024. Scaling LLM Inference with Optimized Sample Compute Allocation. arXiv preprint arXiv:2410.22480 (2024)

    2024 arXiv

  53. [61]

    squeeze

    Tianyi Zhang, Tao Yu, Tatsunori Hashimoto, Mike Lewis, Wen-tau Yih, Daniel Fried, and Sida Wang. 2023. Coder reviewer reranking for code generation. In International Conference on Machine Learning . PMLR, 41832–41846. Syzygy: Dual Code-Test C to (safe) Rust Translation using L...

    2023

Pith tools

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