LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
arXiv:2604.15485v1 [cs.SE] 16 Apr 2026
SARAH BEDELL, Department of Computer Science University of Colorado Colorado Springs (UCCS), USA and & University of Georgia, Athens, GA, USA NAZANIN SIAVASH, Department of Computer Science University of Colorado Colorado Springs (UCCS), USA ARMIN MOIN, Department of Computer Science University of Colorado Colorado Springs (UCCS), USA Abstract. Memory safety has long been a critical challenge in software engineering, particularly for legacy systems written in memory-unsafe languages, such as C and C++. Rust, one of the youngest modern programming languages, offers built-in memory-safety guarantees that make it a strong candidate for secure systems development. Consequently, transpiling C/C++ code into memory-safe Rust code has become a growing area of research. However, manual transpilation is often time-consuming and error-prone. Additionally, rule-based automated approaches are not as flexible or cost-effective as methods enabled by state-of-the-art AI models, techniques, and methods, such as those that deploy Large Language Models (LLMs), for example, Generative Pretrained Transformers (GPT). In this paper, we propose a Retrieval-Augmented Generation (RAG)–assisted framework that integrates an LLM with a Small Language Model (SLM) to perform a C/C++-to-Rust transpilation with a focus on enhancing memory safety. The framework deploys a segmentation strategy that processes C/C++ code in balanced blocks, guiding the LLM with retrieved context from Rust documentation and compiler error references. Our experiments using three OpenAI models (GPT-4o, GPT-4-Turbo, and O3-Mini) demonstrate that the RAG-enhanced pipeline generally improves both code correctness and security for C-to-Rust code transpilation. Several Coreutils programs achieve complete elimination of Raw Pointer Dereferences (RPDs) and Unsafe Type Casts (UTCs) in the final Rust output, indicating the potential of LLM-based transpilation for advancing automated software modernization and repair, as well as memory-safe code generation. CCS Concepts: • Software and its engineering → Software evolution; • Computing methodologies → Artificial intelligence. Additional Key Words and Phrases: large language models, llm, memory safety, code transpilation, ai4se, rust
1
Introduction
For decades, the C programming language has been a cornerstone of low-level software development, powering operating systems, embedded controllers, and applications where efficiency and direct hardware access are paramount. Its fine-grained control over memory and hardware registers has made it indispensable in performance-critical domains. However, this control comes at the cost of manual memory management, which frequently leads to vulnerabilities such as buffer overflows, dangling pointers, and data races. Industry studies have estimated that approximately 70% of reported security vulnerabilities stem from these memory-safety issues [32]. The U.S. federal Authors’ Contact Information: Sarah Bedell, [email protected], Department of Computer Science University of Colorado Colorado Springs (UCCS), Colorado Springs, Colorado, USA and & University of Georgia, Athens, GA, Athens, Georgia, USA; Nazanin Siavash, [email protected], Department of Computer Science University of Colorado Colorado Springs (UCCS), Colorado Spring, Colorado, USA; Armin Moin, [email protected], Department of Computer Science University of Colorado Colorado Springs (UCCS), Colorado Spring, Colorado, USA.
2
Bedell et al.
government has also called for a shift toward memory-safe languages to reduce such risks by design [14, 15]. Rust has emerged as a modern alternative for software system programming that addresses many of these challenges by enforcing a strict ownership-and-borrowing model at compile time, preventing entire classes of memory-safety bugs before execution. Its performance is comparable to C and C++, while its safety guarantees have led to successful adoption in high-profile projects. Despite these advantages, vast amounts of critical infrastructure remain written in C. Migrating this legacy code base to Rust in a manual manner would be both costly and time-consuming. This challenge has motivated a growing interest in automated C-to-Rust transpilation. Existing automatic transpilation (i.e., translation across programming languages) techniques generally fall into two main categories: rule-based and modern-AI-based. The early generation of AI-enhanced systems was rule-based. While effective at maintaining functional equivalence, such methods often generate Rust code that contains unsafe blocks and retains low-level idioms from C, limiting both its maintainability and the security benefits of Rust. In contrast, state-of-the-art AI approaches, for example, based on Large Language Model (LLMs), such as Generative Pretrained Transformers (GPT), can produce more idiomatic and typically more secure Rust code, as these models learn from large corpora of human-written code. However, LLMs suffer from a lack of semantic guarantees and are prone to hallucinations, producing code that deviates from the original intent of the program. Therefore, we explore hybrid solutions that integrate LLMs with external components to combine the fluency of generative models with the determinism of static tools. In this study, we focus on C/C++-to-Rust transpilation to improve memory safety, leveraging Rust’s compile-time enforcements to yield inherently more secure programs. Unlike higher-level memory-safe languages, such as Python or Java, Rust also preserves near-C-level performance, making it a practical target for system-level transpilation. We aim to automate this using cuttingedge LLM-assisted methods and techniques. In particular, our approach combines an LLM (e.g., GPT-4o, GPT-4-Turbo, or o3-mini) with a Retrieval-Augmented Generation (RAG) pipeline that contextualizes the prompts sent to models with relevant code patterns and domain-specific documentation. This design aims to mitigate hallucination-related risks and enhance the idiomatic quality, correctness, and security of the generated Rust code. Our approach also aligns with several prominent initiatives to improve software memory safety, exemplified by the DARPA TRACTOR initiative [1]. We evaluate our proposed approach using a subset of the benchmark introduced by Nitin et al. [27], which comprises seven diverse Coreutils programs originally written in C along with ten existing C2Rust-translated programs. We limit the experiments to the seven Coreutils applications to make it more feasible in terms of scope. However, the dataset’s diversity in program size and functionality provides a meaningful basis for assessing transpilation quality and performance. Additionally, our exploratory interactions with the LLMs indicated a flexibility to address both C and C++ transpilation to Rust. However, we limited the scope of the experimental study in this paper to C code transpilation only. This paper makes the following contributions: (1) We propose a novel transpilation framework that integrates LLMs with a RAG-enhanced pipeline to improve the quality (including security) of C/C++-to-Rust transpilation. (2) We assess the ability of state-of-the-art LLMs to generate memory-safe Rust code while retaining functional equivalence to the original C code. (3) We investigate whether the common hallucination problem in LLM-based code generation can be mitigated by making the LLM more context-aware through augmenting the prompt with targeted retrieval from relevant sources.
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
3
Specifically, we address two Research Questions (RQs): RQ1: Can LLMs effectively and efficiently transpile C code to idiomatic and memory-safe code in Rust? RQ2: Can a RAG-based pipeline reduce the LLM hallucinations for code generation, thus improving the correctness of the LLM-generated/transpiled Rust code? The remainder of this paper is structured as follows. Section 2 provides brief background information on various topics. Section 3 reviews related work in the literature. Next, Section 4 proposes our novel approach. The experimental study in Section 5 validates the proposed approach. Section 6 discusses the results and answers the RQs. Furthermore, we point out a few threats to the validity of the outcomes in Section 7. Finally, Section 8 concludes the paper and outlines directions for future work. 2
Background
Fig. 1. The RAG similarity search process. External documents are embedded into vectors, and a query is embedded into a query vector. Similarity check (e.g., Cosine Similarity) identifies the most relevant document chunks to augment the query with contextual knowledge.
This section provides a general background of code transpilation, LLMs, RAG, memory safety, and Rust, with a central focus on how these concepts relate to the proposed approach of the paper. 2.1
Code Transpilation
Code transpilation, the process of transferring source code from one programming language to another, was historically performed manually using extensive hand-crafted rules and requiring deep domain expertise [21]. While this approach facilitated some early efforts, it proved to be both time-consuming and resource-intensive, ultimately making it inefficient and ineffective. As a result, manual transpilation methods saw limited adoption in practice. In recent developments of software research, there has been a continuous effort to use LLMs to lower the time necessary to transpile code, yet keep the code usable, idiomatic, and efficient [5, 30]. Code transpilation serves various purposes; however, one of the primary focuses of this paper is the improvement of safety by transpiling a program from an unsafe language, such as C or C++, to a safe language, such as Rust. 2.2
Large Language Models (LLMs)
LLMs, in their recent developments, have become a large area of intrigue. While many LLMs are open source and freely available for various applications, it is often the case that user interactions
4
Bedell et al.
contribute to ongoing training, helping improve the model’s accuracy and performance [10]. LLMs can be applied in a wide range of tasks, including storytelling, answering questions, and generating or repairing code. However, producing usable and idiomatic code in high-level languages has historically been a significant challenge for developers working with LLMs. Recent developments have shown that many LLMs are now more proficient at generating usable code than the average developer, with many programs even offering AI assistance for code completion [33], however there are still issues with the code being idiomatic, or legible to human developers [20]. With the increasing attention brought to LLMs, researchers now attempt to solve code transpilation through the new tool at hand [5], hoping to minimize computational costs and time of translation. However, even with the rising abilities that the LLMs have shown, they are still wildly inaccurate, in many areas, and have a tendency to hallucinate in order to maximize efficiency. Hallucinations are shown by the LLMs conjuring up false information as a response to a prompt, creating distrust of LLMs, as well as spreading new falsities as truths [16, 24]. 2.3
Small Language Models (SLMs)
Small Language Models (SLMs) have emerged as efficient alternatives to LLMs, offering several distinctive advantages. Due to their comparatively smaller parameter counts and training datasets, SLMs typically involve a trade-off between predictive accuracy and computational efficiency. However, when provided with adequate contextual information, their performance can be substantially improved. Recent studies have shown that SLMs combined with retrieval-augmented generation (RAG) pipelines can, in certain specialized domains, outperform general-purpose LLMs [26]. Similar to LLMs, SLMs can be either open-source or proprietary. Open-source models such as TinyLlama have gained popularity owing to their accessibility and ability to be deployed locally. SLMs can be highly effective with added context, and have the computational efficiency from their smaller nature, making them useful for highly specified tasks [22]. 2.4
Retrieval Augmented Generation (RAG)
RAG is a technique designed to enhance the quality and relevance of responses generated by an LLM by incorporating external contextual information. In a RAG setup, the coding architect constructs a pipeline that retrieves relevant knowledge from an external source, identifies documents semantically similar to the user query, and integrates that information into the context provided to the LLM for response generation. Figure 1 illustrates this process: the embedded query is compared with document embeddings through similarity search, and the two bolded vectors represent the most relevant document embeddings retrieved. These embeddings are then combined with the query to form an enriched context for the LLM’s response. The external knowledge base can be tailored and segmented by the architect, allowing for taskspecific and domain-focused retrieval. By providing relevant information, a RAG pipeline enables the LLM to access additional knowledge, leading to more accurate and context-aware outputs [6]. This focused retrieval also helps minimize “noise,” or irrelevant information, that can mislead the LLM during generation. Since such noise is a key contributor to hallucinations, there is growing interest in how effectively RAG can mitigate this issue. In other words, integrating RAG with LLMs has demonstrated measurable improvements in the quality and reliability of generated outputs [28], and it holds promise for reducing hallucination rates through context-driven refinement. 2.5
Memory Safety
Memory safety refers to a program’s ability to prevent unauthorized or unintended access to its memory, protecting against issues such as buffer overflows, dangling pointers, heap metadata overwrites, and other forms of memory corruption [4, 34]. Ensuring memory safety is crucial
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
5
for developers to safeguard their software systems, web applications, and distributed services. However, a large portion of legacy software is written in C or C++, languages that inherently lack built-in safety mechanisms [8]. These languages predate many protections now common in modern languages, such as Rust, Python, and Java, such as enforced type safety, ownership models, and concurrency locks. This gap has led to growing interest in translating C/C++ programs into safer languages like Rust. Yet, manual transpilation remains slow, error-prone, and labor-intensive. To address this challenge, recent work has explored the use of LLMs to accelerate the translation process, thereby improving both the efficiency and the security of legacy software systems. 2.6
Rust
Compared to older programming languages, Rust is relatively young; it was first released in 2013. Despite its modern design and extensive safety features, it remains less widespread than established high-level languages such as Python or Java. However, its adoption is rapidly increasing. Rust’s youth is, in fact, one of its advantages: it integrates contemporary programming concepts focused on memory safety, security, and reliability while maintaining computational performance comparable to C [9, 35]. Rust can operate in both safe and unsafe modes [3]. By default, the Rust compiler (rustc) enforces strict safety guarantees that prevent memory-related vulnerabilities. Developers must explicitly use the keyword unsafe to bypass these protections, thereby disabling the compiler’s safety checks when low-level control is required. 3
Related Work
Research and ideas do not exist in a void, instead they are built upon one another, as ideas create pathways for new concepts to take root. Thus, this research is heavily dependent on all of the research that came before it, which was attempting to solve the same, or similar problems. There have been some programs created as a way to automate code translation, regardless of the language, such as UniTrans [36], which increased the efficacy of the LLM attempting to aid in code transpilation. 3.1
Transpiling C/C++ Into Unsafe Rust
Several efforts have been made to automate the translation of C/C++ into unsafe Rust, motivated by the widespread use of C/C++ and the notion that unsafe Rust can later be refined into safe Rust by incorporating appropriate safety measures. Despite ongoing challenges, such as preserving the program’s semantics and resolving type mismatches between the two languages, transpiling to unsafe Rust offers a key advantage: it is significantly simpler. Rust code can be made unsafe by merely adding the unsafe keyword to functions, which is far less complex than manually enforcing all the language’s safety mechanisms and ensuring type compatibility throughout the program. The first notable work in this direction was C2Rust [17], which enabled automated translation from C to non-idiomatic, unsafe Rust. Building on this foundation, more recent research, such as that by Okutan et al. [28], focused on transpiling C++ to Rust with an emphasis on syntax accuracy and execution efficiency rather than security or memory safety. This marks a significant step forward, leveraging C2Rust’s framework to improve accuracy, idiomatic expression, and performance of the generated code. However, these transpilation still fell short of providing the complete memory safety guarantees that distinguish Rust from traditional systems programming languages. In Figure 2, there’s an example of C code being transpiled into Rust code. The small segment comes from the beginning of the program uniq in our dataset. This example comes from our first transpilation of the code using o3-mini.
6
Bedell et al.
Fig. 2. Transpiled C code into Rust using the o3-mini model.
3.2
Transpiling C/C++ Into Safe Rust
Although further improvements are needed to enhance the idiomatic quality and semantic accuracy of the newly transpiled Rust code, the ability to generate generally compilable Rust now opens the door to advancing the memory safety and security of programs once they have been migrated from C/C++. This study builds upon prior research, particularly the work of [27], which achieved the translation of C into a safer version of Rust, improving the safety of lines of code by only 24% and type casts by 8%. Later studies, such as LAC2R, integrated LLMs without RAG, yielding mixed outcomes compared to C2SaferRust, especially on larger datasets [32]. The use of source-to-source transpilers has further improved program reliability by addressing API-level safety rather than focusing solely on syntax [25]. Additionally, Hong and Ryu worked on each individual part of transpiling C into safer Rust, through locks [11], union tags [12], and type casts [13]. Their research provided essential background for our proposed approach, demonstrating continued progress toward fully memory-safe Rust transpilation. While our work does not address locks or union tags, it closely aligns with their investigation into type-cast safety, one of the most error-prone components of C/C++-to-Rust transpilation. 3.3
LLM Hallucination Mitigated by RAG
Significant progress has been made in minimizing LLM hallucinations through the use of RAG pipelines. Recent studies demonstrate that integrating RAG mechanisms, rather than relying solely on traditional parametric sequence-to-sequence models, enhances accuracy in knowledge-intensive NLP tasks [23]. These hybrid models combine parametric and non-parametric memory to improve contextual relevance and factual grounding. Nonetheless, sequence-to-sequence architectures often remain limited in their ability to accurately model conceptual correlations, motivating recent work that applies RAG to better capture the intent of user queries or prompts [19]. Incorporating retrieved external knowledge helps reduce hallucinations and improve the reliability of code transpilation, as shown by [28], where RAG-enabled LLMs were employed to translate C++ into Rust. Further research explored whether generation-augmented retrieval can enhance consistency and factual accuracy even more effectively [31]. More recent efforts examined the failure modes of both standalone LLMs and RAG-enhanced LLM pipelines, proposing the integration of knowledge graphs to address persistent issues of misinformation and contextual drift [2].
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
4
7
Proposed Approach
In this section, we first formalize the problem addressed in this work and relate it to the research questions outlined in Section 1. We then describe the architecture of the proposed framework and explain its main components in detail. 4.1
Problem Formalization
Let us denote an LLM as 𝐿, which performs a software engineering task 𝑀, such as code generation, enhancement, or transpilation, in a programming language 𝑁 . In our study, 𝑀 corresponds to the task of transpiling C/C++ code into Rust, i.e., 𝑁 = {C/C++, Rust}. We define 𝑃 (𝐿, 𝑀) as the correctness and safety performance of model 𝐿 in executing task 𝑀, quantified using compiler-verified metrics that capture memory-safety violations. Specifically, 𝑃 (𝐿, 𝑀) depends on the number of: • Raw Pointer Dereferences (RPDs), • Unsafe Type Casts (UTCs), and • Unsafe Lines of Code (ULoCs). A lower count of these unsafe constructs implies greater memory safety and correctness of the transpiled Rust code. Let 𝐼 denote the input prompt, which represents the source C/C++ function or program to be transpiled. When this prompt is augmented with domain-specific context retrieved by a RAG pipeline, we denote the enriched input as 𝑅𝐴𝐺 (𝐼 ). The corresponding safety performance of 𝐿 under RAG augmentation is represented as 𝑃 (𝐿, 𝑀, 𝑅𝐴𝐺 (𝐼 )). For RQ1, we aim to determine whether LLMs can effectively perform C/C++ → Rust transpilation such that: 𝑃 (𝐿, 𝑀, 𝐼 ) is maximized, i.e., unsafe constructs are minimized. In other words, we evaluate whether 𝐿 can produce idiomatic and memory-safe Rust code from C/C++ inputs. For RQ2, we extend the formulation to a RAG-enhanced variant of the model, denoted 𝐿𝑅𝐴𝐺 , which leverages retrieval of relevant external knowledge. We hypothesize that: 𝑃 (𝐿𝑅𝐴𝐺 , 𝑀, 𝐼 ) > 𝑃 (𝐿, 𝑀, 𝐼 ), indicating that the RAG-augmented model reduces hallucinations and improves the correctness of transpiled Rust code relative to the base LLM. Finally, the hallucination rate 𝐻 (𝐿, 𝑀), defined as the proportion of incorrect or unverifiable constructs generated by 𝐿, is expected to satisfy: 𝐻 (𝐿𝑅𝐴𝐺 , 𝑀) < 𝐻 (𝐿, 𝑀). Thus, our theoretical goal is to show that retrieval-augmented prompting enhances the factual accuracy, and memory safety. 4.2
Architecture of the Proposed Solution
This paper introduces a framework for LLM-assisted C/C++ to Rust transpilation with an explicit focus on memory safety rather than purely idiomatic Rust. At a high level, the approach has three main components: • a segmentation and transpilation pipeline that converts C/C++ code into (initially) unsafe Rust, • a RAG pipeline that provides external context to the LLM during refinement, and • a verification layer that compares LLM-reported safety improvements against compilerverified results.
8
Bedell et al.
Figure 3 illustrates the overall architecture of the proposed approach. We instantiate and evaluate this architecture on a subset of the dataset introduced by [27], consisting of seven GNU Coreutils programs written in C (uniq, cat, pwd, truncate, head, split, and tail). These programs span a range of code sizes and functionalities, providing a diverse set of memory-safety and control-flow patterns.
Fig. 3. Comprehensive Overview of Proposed Approach
Input Segmentation. Our method starts with the full C/C++ source code that we want to convert to Rust. Instead of cutting it up by individual functions, we go through the file one character at a time and keep track of every { and } brace. As we read, we collect the code into a temporary buffer. Whenever the braces are balanced again (meaning every { has a matching }) and the collected code is longer than 500 characters, we save that piece as one segment and start a new one. This approach ensures that the code is never split in the middle of a function or other unbalanced block. Each segment is large enough to give the LLM sufficient context (at least 500 characters) but small enough to stay within the model’s token limits. Depending on the structure of the original file, a single segment may include one large function or several smaller ones that together meet the length and balance conditions. Table 1. Amount of Segments of Code per codeutils Program
Dataset
Program
coreutils
uniq cat pwd truncate head split tail
# of Segments 12 10 12 4 20 22 42
# of LoC 544 693 333 343 932 1494 2205
Table 1 summarizes the number of segments and the original C lines of code (LoC) for each program. The segment count is driven by character length and functional structure rather than LoC alone, so we report both metrics. To further respect token limits, the system is also configured to re-segment any generated Rust file that exceeds a fixed character budget, which may slightly change the final number of segments used in later stages.
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
9
Two-Stage Transpilation to Safe Rust. Before transpilation, a brief natural-language summary of each program’s overall purpose is generated and attached to every segment. This helps maintain global intent when the LLM processes each segment in isolation. The transpilation and refinement pipeline proceeds in two main stages: (1) Initial transpilation to unsafe Rust. Each C/C++ segment, together with the programlevel summary, is sent to the LLM to produce an initial Rust version. At this stage, the model is allowed to use unsafe constructs, raw pointers, and casts as needed to preserve behavior. (2) Refinement to safer Rust. Each initial Rust segment is then passed through a second LLM-based refinement step. In this step, the prompt explicitly instructs the model to: (a) improve general memory safety and security, and (b) specifically reduce or eliminate raw pointer dereferences and unsafe type casts. Once all segments have been refined, they are reassembled into a single Rust file per program that preserves the functional intent of the original C/C++ program. Verification. After the initial and refined Rust versions are constructed, the framework analyzes them along two axes: (1) model-reported safety and (2) compiler-verified safety. First, each segment is examined by the LLM to estimate the number of raw pointer dereferences (RPDs) and unsafe type casts (UTCs) in both the original and refined Rust versions. These selfreported counts provide the model’s own view of how much it believes it has improved memory safety. Second, both versions of the compiled Rust code are passed to the Rust compiler and a custom bash script: • rustc produces error messages, from which we extract specific error codes related to RPDs and UTCs (E0133, E0392, E0793 for RPDs; E0604–E0607 for UTCs). • the script scans the code for unsafe blocks (unsafe {...}) and counts unsafe lines of code (ULoCs) that may hide compilable RPDs and UTCs without triggering explicit compiler errors. This combination allows us to (i) measure the true number of unsafe constructs remaining after refinement and (ii) compare these counts with the LLM’s self-reported values to estimate hallucination rates. Finally, we also track changes in unsafe blocks (UBs) and ULoCs to capture broader improvements in general security beyond RPDs and UTCs alone. RAG Pipeline and Chunking Strategy. The RAG component provides the LLM with retrieval-based context, such as relevant excerpts from Rust documentation, safety best practices, and example patterns for safe pointer handling and casting. Because both the documentation and the generated programs can be large, we apply a chunking strategy driven by token and API limits. For external documents (e.g., the Rust Programming Language book [18]), we initially experiment with 200-character chunks and 20-character overlaps. We later increased this to 500-character chunks with 50-character overlaps to reduce the number of chunks per query, which lowered retrieval latency and token usage without degrading relevance. For large generated Rust files, we first enforce a 5000-character limit per segment; if exceeded, the file is re-chunked into 4000character segments with a 15-character overlap. This ensures that each prompt has sufficient context while staying within OpenAI’s token constraints. Reproducibility and Model Configuration. A key design goal of the framework is to maximize reproducibility of LLM outputs, despite the inherent stochasticity of generative models. To this end, all model calls are configured with temperature = 0 and we consistently use the first returned
10
Bedell et al.
Fig. 4. Annotated Python function showing the four components of the LLM-based transpilation call: (1) system prompt definition, (2) user query input (segment + summary), (3) model invocation with temperature set to zero, and (4) output extraction.
choice (i.e., .choices[0]), as illustrated in Figure 4. This setup reduces randomness and makes it more likely that experiments can be replicated across runs. For this study, we employ three OpenAI models with different capacities and training focuses: • two LLMs: GPT-4o and GPT-4-Turbo, and • one SLM: o3-mini. Using multiple models allows us to investigate whether the observed improvements in memory safety and hallucination reduction are consistent across architectures, directly supporting RQ1 (effectiveness of LLM-based transpilation) and RQ2 (benefits of RAG-assisted code generation). 5
Experimental Study
This section presents the experimental study of our RAG-enhanced framework for transpiling C code into memory-safe Rust. It introduces the dataset of Coreutils programs used for testing, defines the evaluation metrics, and finally reports the experimental results comparing GPT-4o, GPT-4-Turbo, and o3-mini against compiler-verified outputs. 5.1
Dataset
The dataset for this study consists of seven C programs from the GNU Coreutils package [29], uniq, cat, pwd, truncate, head, split, and tail. These utilities were chosen because they are fundamental system-level programs that exhibit a wide range of pointer operations, type casting, and input/output handling patterns in C. Such patterns provide an effective testing ground for evaluating memory safety and type safety in cross-language transpilation tasks. 5.2
Evaluation Metrics
To evaluate the effectiveness of the proposed RAG-enhanced LLM transpilation framework, we use three primary quantitative metrics, RPDs, UTCs, and ULoCs, complemented by compiler-based verification and hallucination detection. (1) Raw Pointer Dereferences (RPDs): Count of dereference operations performed directly on raw pointers. A reduction in RPDs indicates safer memory access and improved pointer management.
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
11
(2) Unsafe Type Casts (UTCs): Instances of unsafe type conversions (e.g., as *const _) that may compromise type or memory safety. The goal is to minimize or eliminate such casts in the transpiled Rust code. (3) Unsafe Lines of Code (ULoCs): Total lines of code encapsulated within unsafe { ... } blocks or functions. This provides a direct measure of how much code bypasses Rust’s compiler-enforced safety guarantees. Additionally, we tracked UBs and Compiler Error Codes: • RPD-related codes: E0133, E0392, E0793 • UTC-related codes: E0604–E0607 These were extracted using a custom bash script that scanned each compiled Rust program for occurrences of unsafe constructs and compiler diagnostics. This validation method ensures reliability and minimizes bias from LLM self-estimation. To compare our approach against state-of-the-art baselines such as C2SaferRust [27] and LAC2R [32], we compute percentage change metrics between the Original Rust (w/o RAG) and Final Rust (w/ RAG) outputs: Countoriginal − Countfinal Change (%) = × 100 Countoriginal A higher percentage indicates a stronger reduction in unsafe constructs and thus greater memory safety improvement. Finally, we qualitatively assessed LLM hallucination by contrasting each model’s self-reported RPD/UTC counts with the verified compiler counts. A smaller deviation between predicted and verified counts suggests better factual grounding and reduced hallucination during code generation. 5.3
Experimental Results
The main goal of this experimental analysis is to assess how effectively different language models can transpile C into memory-safe Rust, and how the integration of a RAG pipeline reduces unsafe constructs and hallucinations. Each model was tested on seven Coreutils programs, and the results were measured in terms of RPDs, UTCs, and ULoCs, both as self-estimated by the models and verified through the Rust compiler 5.3.1 GPT-4o. Table 2 shows the changes in RPDs and UTCs for GPT-4o between the original (w/o RAG) and final Rust (w/ RAG) outputs. While GPT-4o correctly identifies overall trends in memory safety improvements, it slightly overestimates reductions in the tail program, where, based on the comparison between its self-reported (25) and compiler-verified (34) RPD counts, it undercounts approximately 26.5% of the true RPDs and hallucinates a rise in UTCs. In contrast, GPT-4o performs very well on simpler programs such as uniq, pwd, and head, where both RPDs and UTCs are correctly reduced to zero, fully aligning with compiler verification. The model also shows accurate safety improvement trends for cat and split, where the number of unsafe constructs decreases substantially in both self-reported and verified outputs. Overall, GPT-4o captures the direction of improvement accurately and demonstrates strong qualitative reasoning even when its numeric precision varies across larger programs such as tail. 5.3.2 GPT-4-Turbo. Table 3 presents results for GPT-4-Turbo. Although GPT-4-Turbo’s self-reported counts deviate from the compiler-verified results, it achieves the most memory-safe outputs among all tested models. In particular, the model correctly identifies and eliminates nearly all RPDs and UTCs in five of the seven Coreutils programs (uniq, truncate, head, split, and cat), achieving full alignment with compiler verification for most of them. For cat, GPT-4-Turbo predicts a complete removal of RPDs (from 8 to 0) and a substantial reduction of UTCs (from 8 to 1), which closely
12
Bedell et al.
Table 2. Comparison of RPDs and UTCs between the initial (w/o RAG) and final (RAG-enhanced) Rust outputs generated by GPT-4o.
Model
GPT-4o
Program # of RPDs in Original Rust uniq 0 cat 27 pwd 0 truncate 0 head 0 split 18 tail 25
# of RPDs in Final Rust 0 2 0 0 0 2 3
# of UTCs in Originl Rust 3 2 0 0 0 5 3
# of UTCs in Final Rust 0 2 0 2 0 1 4
matches the compiler’s verified counts (5 to 0 and 0 to 0, respectively). Similarly, head and split exhibit strong consistency between the model’s predicted and verified improvements, both showing near-zero unsafe constructs in the final Rust code. The few discrepancies arise primarily in more complex programs such as pwd and tail, where GPT-4-Turbo hallucinates minor RPD increases (1 → 2) or misclassifies residual unsafe casts. These deviations likely stem from the model’s limited ability to track global pointer aliasing or crossfunction data flow in longer code segments. Nevertheless, the compiler results confirm that GPT-4Turbo produces the safest overall Rust outputs, demonstrating strong structural awareness of unsafe constructs and the lowest total number of remaining RPDs and UTCs after RAG enhancement. Table 3. Comparison of RPDs and UTCs between the initial (w/o RAG) and final (RAG-enhanced) Rust outputs generated by GPT-4-Turbo.
Model
Program
GPT-4-Turbo
uniq cat pwd truncate head split tail
# of RPDs in Original Rust 0 8 1 0 1 8 3
# of RPDs in Final Rust 0 0 2 0 0 1 2
# of UTCs in Originl Rust 0 8 1 0 7 9 9
# of UTCs in Final Rust 0 1 0 0 1 0 5
5.3.3 o3-mini. Table 4 displays the results for OpenAI’s o3-mini, an SLM. While o3-mini produces syntactically correct and structurally sound Rust code, it is noticeably less accurate in its estimation of memory safety metrics. The model frequently overstates the degree of improvement between its original and final outputs, showing significant discrepancies when compared to compiler-verified counts in Table 5. For instance, o3-mini reports large reductions in RPDs and UTCs for head (16 → 5 RPDs, 19 → 4 UTCs) and split (18 → 2 RPDs, 5 → 1 UTC), whereas the compiler verification shows a far
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
13
less pronounced improvement. In programs like tail, o3-mini’s hallucinations are more evident: it predicts meaningful safety gains ( 29 → 14 RPDs), yet the compiler reports residual unsafe operations that remain high ( 3 → 14 RPDs). This overconfidence suggests that while o3-mini can apply consistent syntactic transformations, it lacks a deep semantic understanding of memory safety rules. One interesting observation is that o3-mini often includes additional safety directives, such as: # ! [ forbid ( unsafe_code ) ] and # ! [ deny ( u n s a f e _ c o d e ) ] These top-level compiler attributes enhance baseline safety by explicitly forbidding the compilation of unsafe constructs unless explicitly overridden. However, their presence does not necessarily imply the full removal of unsafe blocks (unsafe { ... }) or type-cast violations. In many cases, these directives coexist with unresolved ULoCs and UBs, indicating that o3-mini attempts to enforce safety declaratively rather than eliminating unsafe constructs programmatically. Overall, while o3-mini’s outputs demonstrate strong surface-level code quality and consistent adherence to Rust’s syntax and style conventions, the model exhibits the highest hallucination rate among the evaluated systems. Its safety improvements are often overstated, with large deviations between self-estimated and compiler-verified results. Despite these shortcomings, o3-mini’s inclusion of explicit safety directives shows a distinct behavioral difference from larger LLMs, reflecting a pattern of cautious but superficial enforcement of Rust’s memory-safety guarantees. Table 4. Comparison of RPDs and UTCs between the initial (w/o RAG) and final (RAG-enhanced) Rust outputs generated by OpenAI’s o3-mini.
Model
Program
o3-mini
uniq cat pwd truncate head split tail
# of RPDs in Original Rust 9 7 3 3 16 18 29
# of RPDs in Final Rust 4 9 3 1 5 2 14
# of UTCs in Original Rust 11 9 1 9 19 5 36
# of UTCs in Final Rust 0 9 0 0 4 1 15
5.3.4 Rust Compiler Verification. To obtain ground-truth measurements of memory safety, we use rustc, the Rust compiler, as an external oracle. Rather than relying solely on the models’ self-reported counts of RPDs and UTCs, we compile each Original Rust (w/o RAG) and Final Rust (w/ RAG) program and extract safety-relevant diagnostics. This allows us to quantify how many unsafe constructs remain in each version and to evaluate the extent of LLM hallucination. We focus on two classes of compiler error codes: • RPD-related codes: E0133, E0392, E0793, which correspond to undefined behavior or violations caused by raw pointer dereferences. • UTC-related codes: E0604–E0607, which capture incorrect or unsafe type conversions (e.g., invalid casts or mismatched types).
14
Bedell et al.
For each generated Rust program, we invoke rustc and run a custom bash script that: (1) Parses the compiler output to count occurrences of the above error codes, yielding verified counts of RPDs and UTCs. (2) Scans the source for unsafe { . . . } blocks and unsafe functions to determine: • the number of unsafe blocks (UB), and • the number of unsafe lines of code (ULoCs), by counting lines syntactically enclosed within unsafe regions. (3) Aggregates these measures for each model (GPT-4o, GPT-4-Turbo, o3-mini), each program, and each version (Original vs. Final). Table 5 summarizes the compiler-verified results. Several trends emerge: • GPT-4o achieves substantial reductions in RPDs and ULoCs for programs such as cat, split, and tail. For instance, cat goes from 29 to 0 RPDs and from 97 to 2 ULoCs, while tail drops from 34 to 1 RPD and from 72 to 19 ULoCs. However, small regressions remain (e.g., an additional UTC in truncate), illustrating that safety improvements are not uniform across all programs. • GPT-4-Turbo frequently produces Final Rust code with no RPDs at all and dramatically reduced ULoCs (e.g., split from 114 to 1 ULoC, cat from 35 to 1 ULoC). Some programs (truncate) are fully safe in both versions, while others (tail) retain UTCs and ULoCs, indicating that residual unsafe regions are sometimes necessary or not fully repaired. • o3-mini exhibits more mixed behavior. In some cases it reduces ULoCs (e.g., uniq from 120 to 10), but in others it increases RPDs, UTCs, or ULoCs (e.g., cat and tail), leading to worse safety than the Original Rust. This confirms that o3-mini is less reliable for memory-safety–oriented transpilation, even though it often inserts strict attributes like #![forbid(unsafe_code)] and #![deny(unsafe_code)]. By contrasting Table 5 with the self-reported counts in Tables 2, 3, and 4, we can directly assess hallucination. GPT-4o and GPT-4-Turbo generally get the direction of change right (unsafe constructs decrease) but misestimate exact counts. o3-mini, by contrast, frequently reports improvements that are not reflected in the compiler diagnostics. 6
Discussion
As mentioned earlier, Table 5 presents the compiler-verified results of RPDs and UTCs detected by rustc, representing the ground-truth safety validation for each model’s output. This verification step ensures that the reported metrics accurately reflect the remaining unsafe constructs after compilation, independent of any self-reported LLM estimations. By cross-referencing these compilerverified counts with the LLM-predicted values (Tables 2–4), we are able to quantitatively evaluate each model’s reliability and identify potential hallucinations in its self-assessment. As shown in Table 5, the compiler results reveal that GPT-4o and GPT-4-Turbo align closely with verified safety improvements, while o3-mini exhibits larger deviations. These verified outputs serve as the foundation for calculating percentage changes between the Original Rust (non-RAG) and Final Rust (RAG-enhanced) versions, following the same methodology used in prior works such as [7, 27]. The earlier studies quantified safety improvement as a percentage reduction in unsafe constructs, allowing direct comparison with our RAG-enhanced approach. By allowing the LLM to first self-evaluate its output and then verifying those results through the compiler, we are able to assess both factual accuracy and hallucination behavior. The RAG context significantly narrows the deviation between LLM-estimated and compiler-verified safety counts, demonstrating that contextual retrieval improves factual grounding. Across Tables 2, 3, and 4, the
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
15
o3-mini
GPT-4-Turbo
GPT-4o
Model
Table 5. Compiler-verified counts of RPDs and UTCs in Rust code generated by different models.
Program # of RPDs in Original Rust
# of RPDs in Final Rust
uniq cat pwd truncate head split tail uniq cat pwd truncate head split tail uniq cat pwd truncate head split tail
0 0 0 0 0 0 1 0 0 0 0 0 0 0 4 8 3 0 7 0 14
0 29 0 0 0 12 34 0 5 0 0 0 0 0 1 7 0 0 0 4 3
# of UTCs in Originl Rust 1 1 0 0 0 4 6 0 0 1 0 1 3 1 0 9 0 0 11 13 7
# of UTCs in Final Rust
# of UB # of UB in Origi- in Final nal Rust Rust
# of ULoC in Original Rust
# of ULoC in Final Rust
0 1 0 1 0 0 3 0 0 0 0 0 0 1 0 11 0 0 4 14 13
3 34 0 2 2 5 25 1 10 1 0 11 15 17 7 39 0 4 24 37 39
3 97 0 2 11 99 72 3 35 7 0 19 114 45 120 52 0 4 51 307 92
0 2 0 2 0 19 19 0 1 5 0 1 1 24 10 66 12 5 38 132 94
0 2 0 2 0 7 11 0 1 2 0 1 1 14 5 20 4 5 14 27 51
differences from Table 5 remain minimal for GPT-4o and GPT-4-Turbo, whereas o3-mini shows stronger divergence due to overgeneralization of safety patterns. Since multiple programs achieve full memory safety, i.e., having zero RPDs and/or UTCs in both their original and final versions, we denote these cases as “–” in Tables 6, 7, and 8. Cases marked “!–” represent instances where a previously safe program (count=0) gained new unsafe constructs in the final version, indicating a regression that cannot be expressed as a percentage, as they cannot be divided by their original count. These cases are separate from the cases with negative changes, which are only notable in the o3-mini results. Those with a negative percentage started with a positive count of the unsafe factor, which grew after the revisionary code was run. These notations preserve interpretability while highlighting meaningful transitions in program-level safety. This experimental study was designed around two main RQs as discussed in 1: RQ1: Can LLMs effectively and efficiently transpile C/C++ code to idiomatic and memory-safe Rust? RQ2: Can a RAG pipeline reduce hallucinations and improve the correctness of LLM-generated Rust code? In addressing RQ1, compiler-verified results (Table 5) and comparative performance summaries (Tables 6–8) show that GPT-4o and GPT-4-Turbo achieve significant reductions in unsafe constructs
16
Bedell et al.
Table 6. Change in RPDs by Different Approaches
Program uniq cat pwd truncate head split tail
GPT-4o – 100% – – – 100% 97%
Us GPT-4 turbo – 100% – – !– – –
o3-mini -300% -14% !– – !– – -367%
C2SaferRust 27% 24% 24% 19% 21% 18% 22%
LAC2R 60% 51% 54% 58% 43% 43% 27%
Table 7. Change in UTCs by Different Approaches
Program uniq cat pwd truncate head split tail
GPT-4o – 0% – !– – 100% 50%
GPT-4 Turbo – – 100% – 100% 100% 0%
o3-mini – -22% – – 64% -8% -86%
C2SaferRust 11% 12% 0% 8% 14% 6% 6%
LAC2R 48% 48% 56% 47% 48% 37% 38%
Table 8. Change in ULoCs by Different Approaches
Program uniq cat pwd truncate head split tail
GPT-4o 100% 98% – 0% 100% 81% 74%
GPT-4 Turbo 100% 97% 29% – 95% 99% 47%
o3-mini 92% -27% !– -25% 25% 57% -2%
C2SaferRust 28% 26% 25% 20% 25% 18% 24%
LAC2R 48% 48% 56% 47% 48% 37% 38%
such as RPDs, UTCs, and ULoCs. Both models outperform prior approaches such as C2SaferRust [27] and LAC2R [32] in achieving memory-safe and idiomatic Rust code generation, demonstrating the effectiveness of our framework in safe transpilation. Regarding RQ2, the comparisons between self-reported LLM estimations (Tables 2–4) and compiler-verified results (Table 5) confirm that the integration of the RAG pipeline substantially reduces hallucinations and enhances factual grounding. By retrieving relevant Rust documentation and safety patterns during code generation, the RAG-enhanced LLMs exhibit improved consistency between predicted and verified safety metrics. Collectively, these findings validate that retrievalguided LLMs not only improve memory safety but also enhance the correctness and reliability of cross-language code transpilation.
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
7
17
Threats to Validity
With the usage of LLMs, several threats to validity and reproducibility must be carefully considered. Although our framework incorporates multiple safeguards to ensure consistent and accurate results, LLMs remain stochastic systems whose outputs may vary depending on internal state, prompt phrasing, and contextual retrieval. We therefore recognize that, despite our efforts to mitigate these risks, certain limitations inherent to LLM-based approaches may still affect the validity of our findings. 7.1
Internal Validity
Internal validity refers to the reliability of the experimental setup and the correctness of the procedures used to measure results. A key threat in our study is the potential for LLM hallucination or inconsistent output generation, which can alter the observed number of RPDs, UTCs, or ULoCs. To minimize this, we adopt several safeguards: (1) We employ multiple LLMs (GPT-4o, GPT-4-Turbo, and o3-mini) to cross-check outputs and ensure consistency. (2) We set the temperature parameter to zero to reduce randomness and ensure deterministic responses across runs. (3) We use a RAG-based similarity search to provide highly relevant context to the model, grounding its reasoning and minimizing hallucination. (4) We conduct multi-metric validation by comparing self-reported and compiler-verified safety measures. Together, these steps enhance repeatability and minimize internal bias introduced by model variability. 7.2
External Validity
External validity concerns the generalizability of our results to other datasets, programming languages, or models. Our evaluation is conducted on seven Coreutils programs, representative but limited in scope. While these utilities cover a broad spectrum of memory and pointer operations, more complex software systems may exhibit different behaviors or safety patterns. Future replications on larger and more diverse codebases (e.g., open-source libraries or embedded systems) would be valuable to confirm the broader applicability of our approach. Moreover, results may vary with different model architectures or API versions, which evolve rapidly and may change over time. 7.3
Construct Validity
Construct validity refers to how well the metrics used reflect the intended concepts. Our study relies on compiler error codes (e.g., E0133, E0392, E0793 for RPDs and E0604–E0607 for UTCs) and counts of unsafe code blocks as quantitative indicators of memory safety. While these are well-established proxies, they do not capture all semantic aspects of unsafe behavior (e.g., logical data races or misuses within safe blocks). Nonetheless, these measures provide a reliable, objective approximation of safety compliance, consistent with prior work such as C2SaferRust [27] and LAC2R [32]. 7.4
Conclusion Validity
Conclusion validity relates to the strength of the causal claims drawn from our results. While the RAG-enhanced framework clearly improves safety metrics and reduces hallucinations, small
18
Bedell et al.
variations across runs or across LLMs may still occur. We mitigate this by cross-verifying compiler outputs. However, due to the probabilistic nature of LLMs, absolute determinism cannot be guaranteed, and minor deviations in future reproductions are expected. 8
Conclusion and Future Work
Memory safety has become one of the most critical challenges in modern software engineering, with an increasing emphasis on translating unsafe C/C++ legacy code into safer alternatives such as Rust. While other memory-safe languages like Python and Java have been considered, Rust’s syntactic and structural similarity to C/C++ makes it uniquely suited for systems programming and efficient low-level performance. This work has explored whether LLMs, particularly when enhanced with RAG, can make this transpilation process more effective and less prone to hallucination. Our approach applied a multi-stage RAG-assisted pipeline to segment C/C++ source code and iteratively prompt LLMs to: (1) transpile it into idiomatic Rust, (2) incorporate memory-safety improvements, and (3) estimate potential memory safety violations. These results have been then validated both automatically, through compiler diagnostics and bash-scripted detection of unsafe constructs, and comparatively, using state-of-the-art baselines such as C2SaferRust [27] and LAC2R [32]. Experimental results show that RAG-assisted LLMs generally and substantially improve the memory safety of transpiled code, outperforming prior methods in reducing RPDs and minimizing ULoCs. RAG-enhanced LLMs can not only assist but potentially surpass current automated transpilation methods in achieving memory safety without compromising idiomaticity. Furthermore, they can self-assess their safety improvements with limited hallucination, particularly when guided with targeted contextual retrieval. For future work, we plan to extend this study to larger-scale codebases, particularly the ten LAERTES benchmark datasets, to assess scalability and generalizability. This will involve adapting our pipeline to support Rust-to-Rust reconfiguration and differential verification. Such extensions would allow us to explore whether RAG-assisted LLMs can serve as viable agents in large-scale legacy code migration and memory-safety assurance for industrial systems. Data and Source Code Availability The source code is available in a GitHub repository 1 . Acknowledgments This material is based upon work supported by the U.S. National Science Foundation (NSF) under Grant No. 2349452. Any opinions, findings, conclusions, or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the NSF. In addition, in preparing this paper, we used generative AI tools and models, such as OpenAI’s GPT models and Claude, to assist with the content and programming tasks. References [1] Defense Advanced Research Projects Agency. [n. d.]. TRACTOR: Translating All C To Rust. http://web.archive.org/ web/20080207010024/http://www.808multimedia.com/winnt/kernel.htm. Accessed: 07/18/2025. [2] Garima Agrawal, Tharindu Kumarage, Zeyad Alghamdi, and Huan Liu. 2024. Mindful-RAG: A Study of Points of Failure in Retrieval Augmented Generation. In 2024 2nd International Conference on Foundation and Large Language Models (FLLM). 607–611. doi:10.1109/FLLM63129.2024.10852457 [3] Sacha-Élie Ayoun, Xavier Denis, Petar Maksimović, and Philippa Gardner. 2025. A hybrid approach to semi-automated Rust verification. Proceedings of the ACM on Programming Languages 9, PLDI (2025), 970–992. 1 https://github.com/qas-lab/reu-sarah-bedell
LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation
19
[4] Emery D Berger and Benjamin G Zorn. 2006. DieHard: Probabilistic memory safety for unsafe languages. Acm sigplan notices 41, 6 (2006), 158–168. [5] Sahil Bhatia, Jie Qiu, Niranjan Hasabnis, Sanjit Seshia, and Alvin Cheung. 2024. Verified code transpilation with LLMs. Advances in Neural Information Processing Systems 37 (2024), 41394–41424. [6] Kenneth Ward Church, Jiameng Sun, Richard Yue, Peter Vickers, Walid Saba, and Raman Chandrasekar. 2024. Emerging trends: a gentle introduction to RAG. Natural Language Engineering 30, 4 (2024), 870–881. doi:10.1017/ S1351324924000044 [7] Mehmet Emre, Ryan Schroeder, Kyle Dewey, and Ben Hardekopf. 2021. Translating C to safer Rust. Proc. ACM Program. Lang. 5, OOPSLA, Article 121 (Oct. 2021), 29 pages. doi:10.1145/3485498 [8] Jonáš Fiala, Shachar Itzhaky, Peter Müller, Nadia Polikarpova, and Ilya Sergey. 2023. Leveraging rust types for program synthesis. Proceedings of the ACM on Programming Languages 7, PLDI (2023), 1414–1437. [9] Lennard Gäher, Michael Sammler, Ralf Jung, Robbert Krebbers, and Derek Dreyer. 2024. Refinedrust: A type system for high-assurance verification of Rust programs. Proceedings of the ACM on Programming Languages 8, PLDI (2024), 1115–1139. [10] Desta Haileselassie Hagos, Rick Battle, and Danda B. Rawat. 2024. Recent Advances in Generative AI and Large Language Models: Current Status, Challenges, and Perspectives. IEEE Transactions on Artificial Intelligence 5, 12 (2024), 5873–5893. doi:10.1109/TAI.2024.3444742 [11] Jaemin Hong and Sukyoung Ryu. 2023. Concrat: An Automatic C-to-Rust Lock API Translator for Concurrent Programs. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 716–728. doi:10.1109/ ICSE48619.2023.00069 [12] Jaemin Hong and Sukyoung Ryu. 2024. To Tag, or Not to Tag: Translating C’s Unions to Rust’s Tagged Unions. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (Sacramento, CA, USA) (ASE ’24). Association for Computing Machinery, New York, NY, USA, 40–52. doi:10.1145/3691620.3694985 [13] Jaemin Hong and Sukyoung Ryu. 2024. Type-migrating C-to-Rust translation using a large language model. Empirical Softw. Engg. 30, 1 (Oct. 2024), 38 pages. doi:10.1007/s10664-024-10573-2 [14] The White House. 2024. Back to the Building Blocks: A Path Toward Secure and Measurable Software. Technical Report. The White House. https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-TechnicalReport.pdf Accessed: 2024-09-30. [15] The White House. 2024. National Cybersecurity Strategy Implementation Plan. Technical Report. The White House. https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/05/National-Cybersecurity-StrategyImplementation-Plan-Version-2.pdf Accessed: 2024-09-30. [16] Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, et al. 2025. A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions. ACM Transactions on Information Systems 43, 2 (2025), 1–55. [17] Immunant Inc. [n. d.]. c2rust. https://c2rust.com/ Accessed: 07/18/2025. [18] Steve Klabnik and Carol Nichols. 2018. The Rust Programming Language. No Starch Press, USA. [19] Robin Ko÷, Mustafa Kağan Gürkan, and Fatoş T. Yarman Vural. 2024. ReRag: A New Architecture for Reducing the Hallucination by Retrieval- Augmented Generation. In 2024 9th International Conference on Computer Science and Engineering (UBMK). 961–965. doi:10.1109/UBMK63289.2024.10773428 [20] Rasmus Krebs and Somnath Mazumdar. 2025. Deploy, but verify: Analysing LLM Generated Code Safety. In 2025 33rd Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP). 13–16. doi:10.1109/ PDP66500.2025.00011 [21] Marie-Anne Lachaux, Baptiste Roziere, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised translation of programming languages. arXiv preprint arXiv:2006.03511 (2020). [22] Yo-Seob Lee. 2024. Analysis of Small Large Language Models(LLMs). International Journal of Advanced Smart Convergence 13, 4 (2024), 155–160. [23] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-augmented generation for knowledge-intensive NLP tasks. In Proceedings of the 34th International Conference on Neural Information Processing Systems (Vancouver, BC, Canada) (NIPS ’20). Curran Associates Inc., Red Hook, NY, USA, Article 793, 16 pages. [24] Yihao Li, Pan Liu, Haiyang Wang, Jie Chu, and W. Eric Wong. 2025. Evaluating large language models for software testing. Computer Standards & Interfaces 93 (April 2025), 103942. doi:10.1016/j.csi.2024.103942 [25] 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 2022 IEEE/ACM 44th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). 354–355. doi:10.1145/3510454.3528640 [26] Suqing Liu, Zezhu Yu, Feiran Huang, Yousef Bulbulia, Andreas Bergen, and Michael Liut. 2024. Can Small Language Models With Retrieval-Augmented Generation Replace Large Language Models When Learning Computer Science?.
20
Bedell et al.
In Proceedings of the 2024 on Innovation and Technology in Computer Science Education V. 1 (Milan, Italy) (ITiCSE 2024). Association for Computing Machinery, New York, NY, USA, 388–393. doi:10.1145/3649217.3653554 [27] Vikram Nitin, Rahul Krishna, Luiz Lemos do Valle, and Baishakhi Ray. 2025. C2SaferRust: Transforming C Projects into Safer Rust with NeuroSymbolic Techniques. arXiv:2501.14257 [cs.SE] https://arxiv.org/abs/2501.14257 Accessed: 07/28/2025. [28] Ahmet Okutan, Samuel Merten, Christoph C. Michael, and Ben Ryjikov. 2024. Leveraging RAG-LLM to Translate C++ to Rust. In 2024 International Conference on Assured Autonomy (ICAA). 102–105. doi:10.1109/ICAA64256.2024.00024 [29] Free Software Foundation & GNU Project. 2025. GNU Core Utilities (coreutils) repository – src directory. https: //github.com/coreutils/coreutils/tree/master/src. Accessed: 2025-11-09. [30] Baptiste Roziere, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised translation of programming languages. In Proceedings of the 34th International Conference on Neural Information Processing Systems (Vancouver, BC, Canada) (NIPS ’20). Curran Associates Inc., Red Hook, NY, USA, Article 1730, 11 pages. [31] Zhihong Shao, Yeyun Gong, Yelong Shen, Minlie Huang, Nan Duan, and Weizhu Chen. 2023. Enhancing RetrievalAugmented Large Language Models with Iterative Retrieval-Generation Synergy. In Findings of the Association for Computational Linguistics: EMNLP 2023, Houda Bouamor, Juan Pino, and Kalika Bali (Eds.). Association for Computational Linguistics, Singapore, 9248–9274. doi:10.18653/v1/2023.findings-emnlp.620 [32] HoHyun Sim, Hyeonjoong Cho, Yeonghyeon Go, Zhoulai Fu, Ali Shokri, and Binoy Ravindran. 2025. Large Language Model-Powered Agent for C to Rust Code Translation. arXiv preprint arXiv:2505.15858 (2025). [33] Alexey Svyatkovskiy, Ying Zhao, Shengyu Fu, and Neel Sundaresan. 2019. Pythia: AI-assisted Code Completion System. In Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining (Anchorage, AK, USA) (KDD ’19). Association for Computing Machinery, New York, NY, USA, 2727–2735. doi:10.1145/3292500.3330699 [34] Hui Xu, Zhuangbin Chen, Mingshen Sun, Yangfan Zhou, and Michael R Lyu. 2021. Memory-safety challenge considered solved? An in-depth study with all Rust CVEs. ACM Transactions on Software Engineering and Methodology (TOSEM) 31, 1 (2021), 1–25. [35] 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 [36] 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 Engineering 1, FSE (2024), 1585–1608.