Pith. sign in

REVIEW 2 major objections 7 minor 1 cited by

Translating C To Rust: Lessons from a User Study

T0 review · 2 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read The paper claims that non-expert human programmers can translate real C programs to safe Rust—compiling, CVE-free, near-C-speed—where state-of-the-art automatic tools fail, and explains the translation strategies that make this possible.

desk verdict First user study of C-to-Rust translation, with a genuinely useful strategy catalog; the headline claim about humans vs. tools is only half-validated because the LLM-based tools were never run in their intended mode. read the letter →

arxiv 2411.14174 v2 pith:OUU5MQ6T submitted 2024-11-21 cs.SE cs.CRcs.PL

Ruishi Li , Bo Wang , Tianyu Li , Prateek Saxena , Ashish Kundu This is my paper · ORCID
classification cs.SEcs.CRcs.PL
keywords CtoRusttranslationmemorysafetyuserstudysemanticdatatypeliftingtemporalautomatictoolsfunctionalequivalencegapdifferentialfuzzing
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

This paper reports a user study in which 33 consenting participants, given a 20-day course assignment, translated eight real-world C programs of 322 to 536 lines into safe Rust. The central claim is that these human translators succeeded where current automatic C-to-Rust tools failed: 31 of the 33 produced compiling, purely safe Rust translations, 26 passed self-written tests reaching at least 85% line coverage, and known memory-safety vulnerabilities in two of the benchmark programs were eliminated. The authors argue this matters because it shows full memory safety can be achieved mostly through statically checked Rust abstractions, at end-to-end performance within roughly 20% of the original C, without the heavy runtime overhead typical of compiler-inserted safety checks in C. At the same time, no human translation was fully behaviorally equivalent to the C source under differential fuzzing, which the authors call a 'last mile' problem. The paper distills the successful strategies—semantic data-type lifting plus reference elision and cloning to satisfy Rust's aliasing rules—as a roadmap for future automatic translators.

What carries the argument

The load-bearing mechanism is the human translation strategy the paper names 'semantic data type lifting': instead of mapping C pointers line-by-line to Rust references, users re-express the underlying object as a higher-level Rust type such as String, Vec<T>, Option<T>, or a grouped struct, and then re-implement C library calls as Rust methods or expressions. Two complementary tactics, reference elision and cloning, resolve the Aliasing Xor Mutability (AXM) rule—Rust's requirement that a piece of data be either mutably borrowed once or immutably borrowed many times—by removing pointers whose work the new type absorbs, or by copying data so that reads and writes target separate objects. This machinery is what lets users achieve temporal memory safety statically, without resorting to runtime reference counting.

What would settle it

Run Flourine or Vert on the same eight benchmarks with an externally supplied decomposition that splits each program into components small enough to translate and then merges the component translations automatically; if the merged output compiles in safe Rust and passes the same tests, the paper's claim that automatic tools cannot do this task is overturned. Similarly, a Laertes or Crown translation of shoco or urlparser that eliminates all raw pointers and unsafe blocks and passes the same fuzz tests would directly refute the claim.

Watch

Extended reading notes

Core claim

The core discovery is that the bottleneck in C-to-Rust translation is not memory safety itself but choosing the right high-level Rust data types and restructuring around Rust's ownership and borrowing rules. On eight C programs from the BSD core utilities and two libraries, the study's participants produced safe Rust translations that compile without any 'unsafe' keyword, whereas the compiler-based tools Laertes and Crown left most references as raw pointers and the LLM-based tools Flourine and Vert produced no compilable, safe, whole-program translation. The user translations eliminated the three known CVEs in shoco and urlparser, with temporal safety enforced statically in 95.6% of owning and 99.7% of borrowing references. The closest translation per benchmark usually ran within 20% of the C baseline, and often faster. The same translations, however, differed behaviorally from C on 37% to 100% of fuzz-generated tests, showing that functional equivalence, not safety, is the hard residual problem.

Load-bearing premise

The load-bearing premise is that the four automatic tools were evaluated in a way that gives them a fair chance; in particular, if a decomposition of the benchmark programs into independently translatable and mergeable modules existed that would let Flourine or Vert compile them, the paper's central human-versus-tools comparison would be weakened.

Editorial extensions

If this is right

  • If the paper's central claim is right, organizations can expect non-expert programmers to produce safe, compiling Rust ports of small real-world C programs on a timescale of weeks, eliminating known memory-safety CVEs in the process.
  • Automatic translators should be redesigned around modeling C data types and library APIs as Rust abstractions, rather than only lifting raw pointers to references while preserving C's control flow.
  • LLM-based translators need a workable, mergeable decomposition strategy for whole programs; the paper's decomposition failures identify this as the immediate blocker.
  • Zero-cost static temporal safety appears achievable in practice, so the performance case for migrating C to Rust is stronger than the performance case for full-memory-safety instrumentation of C.
  • A 'last mile' of functional equivalence remains: safe Rust ports should be shipped with differential fuzzing and an explicit specification of which C behaviors may change.

Reading between the lines

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

  • Inference: The study's benchmarks stop at 536 lines, so a natural extension would be to run the same user-study protocol on C programs of several thousand lines to see whether the elision and cloning strategies scale.
  • Inference: The correlated failure patterns across translations of the same C program suggest that some C idioms have a canonical safe-Rust rendering; identifying those idioms could let automatic tools pre-select the right data type.
  • Inference: If the decomposition blocker were solved, the paper's user strategies could be encoded as search heuristics for LLM pipelines—for example, generating type-lifting suggestions first and letting a compiler-guided loop apply elision or cloning.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 7 minor

Summary. The paper reports a user study in which 33 consenting undergraduate students (of 73 invited) translated eight real-world C programs (322-536 LoC) to safe Rust within 20 days. 31 of the 33 produced compiling, safe-Rust translations; 26 of these passed self-written tests reaching at least 85% line coverage. The authors analyze translation strategies (semantic data-type lifting, elision/cloning for aliasing), the security/performance trade-off (mostly static temporal safety, performance usually within 20% of C), functional gaps (none of the translations is behaviorally equivalent to the C source under differential fuzzing), and the efficacy of four automatic tools (Laertes, Crown, Flourine, Vert). A post-hoc analysis of the uutils/coreutils project is used to test how well the findings generalize.

Significance. The study is carefully designed: IRB exemption, anonymization, post-grade analysis, multiple benchmarks and translators, fuzzing to expose behavioral discrepancies, and a post-hoc check against a mature open-source project. If the findings hold, they provide the first credible evidence that non-expert humans can translate C to memory-safe Rust with acceptable performance, and the identified strategies (semantic data-type lifting, global-to-local refactoring, union-to-enum conversion) are actionable for future automatic translation tools. The principal weakness is that the comparative claim against automatic tools is not fully supported for the LLM-based tools.

major comments (2)
  1. [Section VII-B] The evaluation of Flourine and Vert does not follow the tools' intended component-wise workflow. The authors fed whole 322-536 LoC programs and then tried manual splits, which produced compilable components that could not be merged back into a single program. They explicitly state: 'We are not aware of better ways to decompose our C programs in components small enough to feed to Flourine or Vert.' This leaves open the possibility that a workable decomposition exists and would allow one or both tools to produce a compiling safe-Rust translation on these benchmarks. Since the abstract's central claim is that 'state-of-the-art automatic tools are not able to do so,' this is a load-bearing gap. The claim should be either restricted to whole-program evaluation or to the compiler-based tools, or the authors should demonstrate the infeasibility of decomposition (e.g., by attempting systematic decomposition strategies and reporting the failures in detail).
  2. [Abstract and Sections III/VI] The claim that participants 'are able to produce safe Rust translations' is ambiguous. The paper defines safety as 'safe Rust' without the unsafe keyword, but the task requirements also demanded 'equivalent external behavior.' Section VI shows that none of the 31 translations is fully behaviorally equivalent to the C source, with 37%-100% (68% on average) of fuzz tests exhibiting a discrepancy. The abstract should be qualified to distinguish memory safety from functional equivalence, so that readers do not infer that the translations are fully correct substitutes for the C programs.
minor comments (7)
  1. [Section III (Collected Translations)] The text says participants 'achieved 70% to 98% line coverage' and then 'nearly all of them have coverage above 80%,' but two translations are later reported to have coverage below 80%; please make the wording precise.
  2. [Section V-A, Table III] The categories 'Nullable' and 'DST' overlap with the earlier 'Owning' and 'Borrowing' rows; a sentence explaining whether these are subcategories or disjoint sets would improve readability.
  3. [Section VI, Fig. 9] The legend 'all fail 2 fail 1 fail no fail' is ambiguous; it should be phrased as 'all translations fail / two translations fail / one translation fails / no translation fails.'
  4. [Section VII-B] The sentence '6 out of 8 of our C benchmarks are real-world standalone programs' is correct, but the earlier description of the benchmarks in Section III says 6 from BSDCoreUtils and 2 libraries; aligning the two presentations would avoid confusion.
  5. [References] References [45] and [46] appear to refer to the same CCured paper; this duplicate should be removed.
  6. [Section VIII] The phrase '17.6k Github stars' should be '17.6k GitHub stars,' and the commit date is already given but the reference would benefit from a formal citation.
  7. [Appendix B] The bugfix example uses the unicode-width crate, but the task description in Section III says third-party dependencies are allowed if well-maintained; please note this explicitly in the appendix so readers understand the allowed dependency.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper is an empirical user study whose central claims rest on measured outcomes against independent benchmarks and tools, not on fitted definitions or self-citations.

full rationale

This manuscript does not present a derivation chain; it reports a user study measuring whether human participants can translate C programs to safe Rust and compares those results with four automatic tools. The abstract's central comparative claim -- 'Our participants are able to produce safe Rust translations, whereas state-of-the-art automatic tools are not able to do so' -- is supported by directly observed artifacts: 31 of 33 consenting participants produced compiling safe-Rust translations, 26 passed self-written tests reaching at least 85% coverage, known CVEs were eliminated, and Laertes, Crown, Flourine, and Vert failed to produce safe, compilable translations on the same benchmarks. None of these quantities is defined in terms of another claimed output, and no fitted parameter is later renamed as a prediction. The authors do cite their own prior work in related-work contexts (e.g., references [31], [49], and [59]), but these citations are background context for memory-safety defenses and do not carry the paper's empirical conclusions. The closest concern to circularity is the evaluation of the LLM-based tools Flourine and Vert, which are designed for decomposed inputs but were run whole-program because the authors could not find a workable decomposition; this is a validity threat about fairness of comparison, not a circular step, because the tools' failure is an observed outcome under a stated experimental condition rather than a conclusion pre-encoded in the paper's setup. The paper is also transparent about this limitation in Section VII-B, explicitly stating, 'We are not aware of better ways to decompose our C programs in components small enough to feed to Flourine or Vert.' A threat to external validity or a potentially unfair benchmark condition is not an instance of circular reasoning under the definitions used here. The human-side results are independently grounded: compilation by rustc, line coverage by participant-written tests, differential fuzzing against C behavior, and performance measurement against the original C programs. Therefore, no circularity score above zero is warranted.

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

No free parameters were fitted; the study is observational. The central claims rest on domain assumptions about Rust's safety guarantees, participant representativeness, test adequacy, and fuzzing adequacy. No new entities are postulated.

assumptions (4)
  • domain assumption Safe Rust programs, as defined by the Rust type and borrow system, are memory-safe by construction; the RustBelt result [36] is accepted as grounding.
    Underlies the claim that user translations eliminate known CVEs without requiring further verification.
  • domain assumption The 33 consenting participants are representative enough of non-expert Rust users for the observed strategies and success rates to generalize.
    Only 33 of 73 invited students consented; consent may correlate with skill. Section III, Ethical Concerns.
  • domain assumption Line coverage of at least 85% on self-written tests is an adequate proxy for functional correctness of translations.
    Used to declare 26 of 31 translations successful; later fuzzing shows all translations have behavioral differences, so this proxy is weak.
  • domain assumption Differential fuzzing with AFL++ (1 hour per program, up to 300 sampled tests) is sufficient to characterize behavioral equivalence gaps.
    Underlies Section VI's claim that none of the 31 translations is fully equivalent; fuzzing coverage is bounded, so remaining discrepancies may be missed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Translating C To Rust: Lessons from a User Study." pith.science (2026). https://pith.science/paper/OUU5MQ6T

@misc{pith2026241114174,
  author       = {Pith},
  title        = {Pith review of: Translating C To Rust: Lessons from a User Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OUU5MQ6T}},
  note         = {Machine review of arXiv:2411.14174}
}
read the original abstract

Rust aims to offer full memory safety for programs, a guarantee that untamed C programs do not enjoy. How difficult is it to translate existing C code to Rust? To get a complementary view from that of automatic C to Rust translators, we report on a user study asking humans to translate real-world C programs to Rust. Our participants are able to produce safe Rust translations, whereas state-of-the-art automatic tools are not able to do so. Our analysis highlights that the high-level strategy taken by users departs significantly from those of automatic tools we study. We also find that users often choose zero-cost (static) abstractions for temporal safety, which addresses a predominant component of runtime costs in other full memory safety defenses. User-provided translations showcase a rich landscape of specialized strategies to translate the same C program in different ways to safe Rust, which future automatic translators can consider.

Figures

Figures reproduced from arXiv: 2411.14174 by the authors.

Figure 1
Figure 1. A Rust code example showing the concepts of owner [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. A safe Rust translation of the C program (Version A) [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 2
Figure 2. (Top) An example of C program with aliasing pointers, [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figures from the paper (15 more)
Figure 6
Figure 6. Figure 6: A Line-by-line Rust translation that fails to compile. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Possible translations of the C program (Version B) [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Running time of the most similar Rust translation [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: Rust translations of the same C program all fail on a [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 10
Figure 10. Figure 10: Behavioral differences across 31 translations with tests from greybox fuzzing. Legends from left to right mean “equiv￾alent behaviors” (green), “I/O enc. errors” (gray), “Runtime safety aborts” (brown), and “Logical differences” (red) [PITH_FULL_IMAGE:figures/full_fi…
Figure 4
Figure 4. Figure 4: We find that Rust data types used in uutils programs are similar to the types seen in this study. 83% of the data types in uutils programs also exist in translations by our users. The most frequent Rust types in uutils programs are string￾related types such as String (…
Figure 11
Figure 11. Figure 11: Case Study 1: The spatial memory issue in the [PITH_FULL_IMAGE:figures/full_fig_p016_11.png]
Figure 12
Figure 12. Figure 12: Case Study 2: The temporal memory issue in the [PITH_FULL_IMAGE:figures/full_fig_p017_12.png]
Figure 14
Figure 14. Figure 14: A highlighted block of code of the C example program [PITH_FULL_IMAGE:figures/full_fig_p018_14.png]
Figure 15
Figure 15. Figure 15: The fixed Translation A where the data type of [PITH_FULL_IMAGE:figures/full_fig_p018_15.png]
Figure 17
Figure 17. Figure 17: (Top) A part of the printf C program with a mutable gargv. (Bottom) A Rust translation using strategy A: Moving globals to locals. Translating Mutable Globals (Strategy A + Structs) 1 // fmt.c 2 static int centerP = 0; 3 static size_t x; 4 // ... 15 globals in total 5…
Figure 19
Figure 19. Figure 19: (Top) A part of the csplit C program with mutable globals. (Bottom) A Rust translation using strategy B: dynamic references. (B) Dynamic References [PITH_FULL_IMAGE:figures/full_fig_p019_19.png]
Figure 18
Figure 18. Figure 18: (Top) A part of the fmt C program with mutable globals. (Bottom) A Rust translation using strategy A and group globals into structs. (A) From Globals to Locals [PITH_FULL_IMAGE:figures/full_fig_p019_18.png]
Figure 20
Figure 20. Figure 20: (Top) A part of the csplit C program with mutable globals. (Bottom) A Rust translation using strategy C: atomics. Translating Unions as Enum 1 // shoco.c 2 union Code { 3 uint32_t word; 4 char bytes[4]; 5 }; 6 size_t shoco_compress(...) { 7 union Code code; 8 while //…
Figure 21
Figure 21. Figure 21: (Top) A part of the shoco C program that uses tagged unions. (Bottom) A Rust translation that translates tagged union into enum. Translating Unions. There are two different use cases of C union observed in our benchmarks, including (A) type punning and (B) variant rec…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

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

    cs.SE 2024-12 conditional novelty 7.0 of 10

    A dual code-and-test generation pipeline with dynamic-analysis specifications translates the 3,000-line Zopfli C library into safe Rust, though the top-level validation compares compression ratios rather than exact outputs.

Reference graph

Works this paper leans on

65 extracted references · 57 canonical work pages · cited by 1 Pith paper

  1. [1]

    C ++ core guidelines

    “C ++ core guidelines.” [Online]. Available: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines# i2-avoid-non-const-global-variables

    work page

  2. [2]

    A command-line benchmarking tool

    “A command-line benchmarking tool.” [Online]. Available: https: //github.com/sharkdp/hyperfine

    work page

  3. [3]

    Developer echosystem 2023: Rust

    “Developer echosystem 2023: Rust.” [Online]. Available: https: //www.jetbrains.com/lp/devecosystem-2023/rust/

    work page 2023

  4. [4]

    Dynamically sized types

    “Dynamically sized types.” [Online]. Available: https: //doc.rust-lang. org/reference/dynamically-sized-types.html

    work page

  5. [5]

    Google c ++ style guide: Static and global variables

    “Google c ++ style guide: Static and global variables.” [Online]. Available: https: //google.github.io/styleguide/cppguide.html# Static and Global Variables

    work page

  6. [6]

    The heartblead bug (cve-2014-0160)

    “The heartblead bug (cve-2014-0160).” [Online]. Available: https: //heartbleed.com/

    work page 2014

  7. [7]

    Linux kernel coding style

    “Linux kernel coding style.” [Online]. Available: https: //www.kernel. org/doc/html/next/process/coding-style.html

    work page

  8. [8]

    Oxidation

    “Oxidation.” [Online]. Available: https: //wiki.mozilla.org/Oxidation

    work page

Show all 65 references
  1. [9]

    References and borrowing - the rust programming language

    “References and borrowing - the rust programming language.” [Online]. Available: https: //doc.rust-lang.org/book/ ch04-02-references-and-borrowing.html

  2. [10]

    Thread local storage (rust)

    “Thread local storage (rust).” [Online]. Available: https: //doc.rust-lang. org/src/std/thread/local.rs.html#37

  3. [11]

    Thread local storage (rust standard library)

    “Thread local storage (rust standard library).” [Online]. Available: https://doc.rust-lang.org/src/std/thread/local.rs.html

  4. [12]

    Type punning

    “Type punning.” [Online]. Available: https: //en.wikipedia.org/wiki/ Type punning

  5. [13]

    ”the web /local

    “”the web /local” boundary is fuzzy: A security study of chrome’s process-based sandboxing,” Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016. [Online]. Available: https://api.semanticscholar.org/CorpusID:7573477

    2016

  6. [14]

    Arm MTE architecture: Enhancing memory safety,

    “Arm MTE architecture: Enhancing memory safety,” 8 2019. [Online]. Available: https://community.arm.com/arm-community-blogs/ b/architectures-and-processors-blog /posts/enhancing-memory-safety

    2019

  7. [15]

    Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Code,

    “Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Code,” Jan. 2024, arXiv:2308.03109 [cs]. [Online]. Available: http://arxiv.org/abs/2308.03109

    2024 arXiv

  8. [16]

    Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs,

    C. Cadar, D. Dunbar, and D. R. Engler, “Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs,” in USENIX Symposium on Operating Systems Design and Implementation,

  9. [17]

    Rad: a compile-time solution to buffer overflow attacks,

    T. cker Chiueh and F.-H. Hsu, “Rad: a compile-time solution to buffer overflow attacks,” Proceedings 21st International Conference on Distributed Computing Systems , pp. 409–417, 2001. [Online]. Available: https://api.semanticscholar.org/CorpusID:32026510

    2001

  10. [18]

    Ownership types: A survey,

    D. Clarke, J. ¨Ostlund, I. Sergey, and T. Wrigstad, “Ownership types: A survey,” in Aliasing in Object-Oriented Programming , 2013. [Online]. Available: https://api.semanticscholar.org/CorpusID:15940253

    2013

  11. [19]

    Dependent types for low-level programming,

    J. Condit, M. Harren, Z. Anderson, D. Gay, and G. C. Necula, “Dependent types for low-level programming,” in Proceedings of the 16th European Symposium on Programming , ser. ESOP’07. Berlin, Heidelberg: Springer-Verlag, 2007, p. 520–535

    2007

  12. [20]

    Stackguard: Automatic adaptive detection and prevention of bu ffer-overflow attacks,

    C. Cowan, “Stackguard: Automatic adaptive detection and prevention of bu ffer-overflow attacks,” in USENIX Security Symposium , 1998. [Online]. Available: https://api.semanticscholar.org/CorpusID:2358856

    1998

  13. [21]

    E ffectivesan: type and memory error detection using dynamically typed c /c++,

    G. J. Duck and R. H. C. Yap, “E ffectivesan: type and memory error detection using dynamically typed c /c++,” SIGPLAN Not. , vol. 53, no. 4, p. 181–195, Jun. 2018. [Online]. Available: https://doi.org/10.1145/3296979.3192388 14

    2018

  14. [22]

    Checked c: Making c safe by extension,

    A. S. Elliott, A. Ruef, M. W. Hicks, and D. Tarditi, “Checked c: Making c safe by extension,” 2018 IEEE Cybersecurity Development (SecDev) , pp. 53–60, 2018. [Online]. Available: https: //api.semanticscholar.org/ CorpusID:53413266

    2018

  15. [23]

    Aliasing limits on translating c to safe rust,

    M. Emre, P. Boyland, A. Parekh, R. Schroeder, K. Dewey, and B. Hard- ekopf, “Aliasing limits on translating c to safe rust,” Proceedings of the ACM on Programming Languages, vol. 7, no. OOPSLA1, pp. 551–579, 2023

    2023

  16. [24]

    Translating c to safer rust,

    M. Emre, R. Schroeder, K. Dewey, and B. Hardekopf, “Translating c to safer rust,” Proceedings of the ACM on Programming Languages , vol. 5, no. OOPSLA, pp. 1–29, 2021

    2021

  17. [25]

    Towards translating real-world code with llms: A study of translating to rust,

    H. F. Eniser, H. Zhang, C. David, M. Wang, B. Paulsen, J. Dodds, and D. Kroening, “Towards translating real-world code with llms: A study of translating to rust,” arXiv preprint arXiv:2405.11514 , 2024

    2024 arXiv

  18. [26]

    Afl ++: combining incremental steps of fuzzing research,

    A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “Afl ++: combining incremental steps of fuzzing research,” in Proceedings of the 14th USENIX Conference on Offensive Technologies, ser. WOOT’20. USA: USENIX Association, 2020

    2020

  19. [27]

    Flow-sensitive type qualifiers,

    J. S. Foster, T. Terauchi, and A. Aiken, “Flow-sensitive type qualifiers,” in Proceedings of the ACM SIGPLAN 2002 Conference on Program- ming language design and implementation , 2002, pp. 1–12

    2002

  20. [28]

    Program repair,

    X. Gao, Y . Noller, and A. Roychoudhury, “Program repair,” 2022. [Online]. Available: https://arxiv.org/abs/2211.12787

    2022 arXiv

  21. [29]

    Oss-fuzz vulnerabilities github repository,

    Google, “Oss-fuzz vulnerabilities github repository,” accessed: July,

  22. [30]

    Sticky tags: Efficient and deterministic spatial memory error mitigation using persistent memory tags,

    F. Gorter, T. Kroes, H. Bos, and C. Giu ffrida, “Sticky tags: Efficient and deterministic spatial memory error mitigation using persistent memory tags,” in 2024 IEEE Symposium on Security and Privacy (SP) . IEEE Computer Society, 2024, pp. 217–217

    2024

  23. [31]

    Data-oriented programming: On the expressiveness of non-control data attacks,

    H. Hu, S. Shinde, S. Adrian, Z. L. Chua, P. Saxena, and Z. Liang, “Data-oriented programming: On the expressiveness of non-control data attacks,” in 2016 IEEE Symposium on Security and Privacy (SP). IEEE, 2016, pp. 969–986

    2016

  24. [32]

    Using safety properties to generate vulnerability patches,

    Z. Huang, D. Lie, G. Tan, and T. Jaeger, “Using safety properties to generate vulnerability patches,” 2019 IEEE Symposium on Security and Privacy (SP) , pp. 539–554, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:106401501

    2019

  25. [33]

    c2rust: Migrate C code to Rust,

    Immunant, “c2rust: Migrate C code to Rust,” https: //github.com/ immunant/c2rust, accessed: July 4, 2023

    2023

  26. [34]

    Cyclone: A safe dialect of c,

    T. Jim, G. Morrisett, D. Grossman, M. W. Hicks, J. Cheney, and Y . Wang, “Cyclone: A safe dialect of c,” in USENIX Annual Technical Conference, General Track , 2002. [Online]. Available: https://api.semanticscholar.org/CorpusID:5958340

    2002

  27. [35]

    Practical {Data-Only} attack generation,

    B. Johannesmeyer, A. Slowinska, H. Bos, and C. Giu ffrida, “Practical {Data-Only} attack generation,” in 33rd USENIX Security Symposium (USENIX Security 24) , 2024, pp. 1401–1418

    2024

  28. [36]

    Rustbelt: Securing the foundations of the rust programming language,

    R. Jung, J.-H. Jourdan, R. Krebbers, and D. Dreyer, “Rustbelt: Securing the foundations of the rust programming language,” Proceedings of the ACM on Programming Languages , vol. 2, no. POPL, pp. 1–34, 2017

    2017

  29. [37]

    A hybrid alias analysis and its application to global variable protection in the linux kernel,

    G. Li, H. Zhang, J. Zhou, W. Shen, Y . Sui, and Z. Qian, “A hybrid alias analysis and its application to global variable protection in the linux kernel,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 4211–4228

    2023

  30. [38]

    A formal model of checked c,

    L. Li, Y . Liu, D. Postol, L. Lampropoulos, D. Van Horn, and M. Hicks, “A formal model of checked c,” in 2022 IEEE 35th Computer Security Foundations Symposium (CSF), 2022, pp. 49–63

    2022

  31. [39]

    Pac it up: Towards pointer integrity using arm pointer authentication,

    H. Liljestrand, T. Nyman, K. Wang, C. C. Perez, J.-E. Ekberg, and N. Asokan, “Pac it up: Towards pointer integrity using arm pointer authentication,” ArXiv, vol. abs /1811.09189, 2018. [Online]. Available: https://api.semanticscholar.org/CorpusID:53721743

    2018 arXiv

  32. [40]

    C to checked c by 3c,

    A. Machiry, J. Kastner, M. McCutchen, A. Eline, K. Headley, and M. W. Hicks, “C to checked c by 3c,” Proceedings of the ACM on Programming Languages, vol. 6, pp. 1 – 29, 2022. [Online]. Available: https://api.semanticscholar.org/CorpusID:247748774

    2022

  33. [41]

    Bsd coreutils is a port of many utilities from bsd to linux and macos,

    D. Magdaleno, “Bsd coreutils is a port of many utilities from bsd to linux and macos,” accessed: April, 2024. [Online]. Available: https://github.com/DiegoMagdaleno/BSDCoreUtils

    2024

  34. [42]

    Hybrid concolic testing,

    R. Majumdar and K. Sen, “Hybrid concolic testing,” 29th International Conference on Software Engineering (ICSE’07) , pp. 416–426, 2007. [Online]. Available: https://api.semanticscholar.org/CorpusID:6760091

    2007

  35. [43]

    Softbound: highly compatible and complete spatial memory safety for c,

    S. Nagarakatte, J. Zhao, M. M. K. Martin, and S. Zdancewic, “Softbound: highly compatible and complete spatial memory safety for c,” in ACM-SIGPLAN Symposium on Programming Language Design and Implementation , 2009. [Online]. Available: https: //api. semanticscholar.org/Corpus...

    2009

  36. [44]

    Cets: compiler enforced temporal safety for c,

    ——, “Cets: compiler enforced temporal safety for c,” in International Symposium on Mathematical Morphology and Its Application to Signal and Image Processing , 2010. [Online]. Available: https: //api.semanticscholar.org/CorpusID:914358

    2010

  37. [45]

    Ccured: Type-safe retrofitting of legacy software,

    G. C. Necula, J. Condit, M. Harren, S. McPeak, and W. Weimer, “Ccured: Type-safe retrofitting of legacy software,” ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 27, no. 3, pp. 477–526, 2005

    2005

  38. [46]

    Ccured: type-safe retrofitting of legacy software,

    ——, “Ccured: type-safe retrofitting of legacy software,” ACM Trans. Program. Lang. Syst., vol. 27, pp. 477–526, 2005. [Online]. Available: https://api.semanticscholar.org/CorpusID:8303920

    2005

  39. [47]

    libmpk: Software abstraction for intel memory protection keys (intel {MPK}),

    S. Park, S. Lee, W. Xu, H. Moon, and T. Kim, “libmpk: Software abstraction for intel memory protection keys (intel {MPK}),” in 2019 USENIX Annual Technical Conference (USENIX ATC 19) , 2019, pp. 241–254

    2019

  40. [48]

    Symbolic execution with symcc: Don’t interpret, compile!

    S. Poeplau and A. Francillon, “Symbolic execution with symcc: Don’t interpret, compile!” in USENIX Security Symposium , 2020. [Online]. Available: https://api.semanticscholar.org/CorpusID:221178890

    2020

  41. [49]

    Localizing vulnerabilities statistically from one exploit,

    S. Shen, A. Kolluri, Z. Dong, P. Saxena, and A. Roychoudhury, “Localizing vulnerabilities statistically from one exploit,” in Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security , ser. ASIA CCS ’21. New York, NY , USA: Association for Computing ...

    2021

  42. [50]

    Provenfix: Temporal property guided program repair,

    Y . SONG, X. GAO, W. LI, W.-N. CHIN, and A. ROYCHOUDHURY , “Provenfix: Temporal property guided program repair,” 2024

    2024

  43. [51]

    Sok: Eternal war in memory,

    L. Szekeres, M. Payer, T. Wei, and D. Song, “Sok: Eternal war in memory,” in 2013 IEEE Symposium on Security and Privacy . IEEE, 2013, pp. 48–62

    2013

  44. [52]

    Address space layout randomization

    T. P. Team, “Address space layout randomization.” [Online]. Available: https://pax.grsecurity.net/docs/aslr.txt

  45. [53]

    Enforcing forward-edge control-flow integrity in gcc & llvm,

    C. Tice, T. Roeder, P. Collingbourne, S. Checkoway, ´U. Erlingsson, L. Lozano, and G. Pike, “Enforcing forward-edge control-flow integrity in gcc & llvm,” in USENIX Security Symposium , 2014. [Online]. Available: https://api.semanticscholar.org/CorpusID:6034518

    2014

  46. [54]

    Exec shield,

    A. van de Ven and I. Molnar, “Exec shield,” 2004

    2004

  47. [55]

    The realities of language conversions,

    C. Verhoef and A. Terekhov, “The realities of language conversions,” IEEE Software , vol. 17, no. 6, pp. 111–124, Dec. 2000. [Online]. Available: http://ieeexplore.ieee.org/document/895180/

    2000

  48. [56]

    Cheri: A hybrid capability-system architecture for scalable software compartmentalization,

    R. N. M. Watson, J. Woodru ff, P. G. Neumann, S. W. Moore, J. Anderson, D. Chisnall, N. H. Dave, B. Davis, K. Gudka, B. Laurie, S. J. Murdoch, R. M. Norton, M. Roe, S. D. Son, and M. Vadera, “Cheri: A hybrid capability-system architecture for scalable software compartmentaliza...

    2015

  49. [57]

    An e fficient and backwards- compatible transformation to ensure memory safety of c programs,

    W. Xu, D. C. DuVarney, and R. Sekar, “An e fficient and backwards- compatible transformation to ensure memory safety of c programs,” in Proceedings of the 12th ACM SIGSOFT twelfth international sympo- sium on Foundations of software engineering , 2004, pp. 117–126

    2004

  50. [58]

    VERT: Verified Equivalent Rust Transpilation with Large Language Models as Few-Shot Learners,

    A. Z. H. Yang, Y . Takashima, B. Paulsen, J. Dodds, and D. Kroening, “VERT: Verified Equivalent Rust Transpilation with Large Language Models as Few-Shot Learners,” May 2024. [Online]. Available: http://arxiv.org/abs/2404.18852

    2024 arXiv

  51. [59]

    Capstone: A capability-based foundation for trustless secure memory access (extended version),

    J. Yu, C. Watt, A. Badole, T. E. Carlson, and P. Saxena, “Capstone: A capability-based foundation for trustless secure memory access (extended version),” ArXiv, vol. abs /2302.13863, 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:257220126

    2023 arXiv

  52. [60]

    Ownership guided c to rust translation,

    H. Zhang, C. David, Y . Yu, and M. Wang, “Ownership guided c to rust translation,” arXiv preprint arXiv:2303.10515 , 2023

    2023 arXiv

  53. [61]

    Fat pointers for temporal memory safety of c,

    J. Zhou, J. Criswell, and M. W. Hicks, “Fat pointers for temporal memory safety of c,” Proceedings of the ACM on Programming Languages, vol. 7, pp. 316 – 347, 2022. [Online]. Available: https://api.semanticscholar.org/CorpusID:251903483 15 Appendix A. Case Studies with Memory ...

    2022

  54. [64]

    #url␣=>\n

    Logical Errors that Require More Thorough Testing 16 (a) Code example related to the temporal memory issue 1 // urlparser.c 2 url_data_t *url_parse (char *url) { 3 url_data_t *data = malloc(sizeof(url_data_t)); 4 data->href = url; // Store the pointer 5 } 6 void url_data_inspe...

  55. [65]

    Center" C Output:

    Semantic Di fferences that are Not Easy to Fix Passing Test (Translation A) Executed command: ./fmt -c -w 10 Input: "Center" C Output: " Center" // 2 leading padding spaces Rust Output: " Center" // same as C Failing Test 1 Executed command: ./fmt -c -w 10 Input: "z\u00df\u6c3...

  56. [2008]

    Available: https: //api.semanticscholar.org/CorpusID: 2520229

    [Online]. Available: https: //api.semanticscholar.org/CorpusID: 2520229

  57. [2024]

    Available: https: //github.com/google/oss-fuzz-vulns

    [Online]. Available: https: //github.com/google/oss-fuzz-vulns

Pith tools

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