Pith. sign in

REVIEW 3 major objections 5 minor 80 references

Translation Tag Team: Formal Rules and LLMs Translate More Macros Together than Apart

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

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

Pith's one-line read Formal translation rules and LLMs translate more C macros as a tag team than either does alone.

desk verdict Useful benchmark and tag-team evaluation, but Rule I's const placement breaks pointer types and the universal correctness claim is not established. read the letter →

arxiv 2608.06705 v2 pith:NLNNJ6GJ submitted 2026-08-07 cs.SE

Brent Pappas , Joseph Zalusky , Zachary Burkett , Paul Gazzillo This is my paper · ORCID
classification cs.SE
keywords CpreprocessormacrosmacrotranslationformalinferenceruleslargelanguagemodelsprogramtoRustbenchmarksemanticanalysis
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 tries to show that C preprocessor macros can be translated into ordinary C variables, enums, and functions without changing their call sites, and that this step is what makes macro-heavy C code translatable without losing its abstractions. It claims MerC, a rule-based translator built from seven formal inference rules, never emits an incorrect translation, but only covers half of a new 398-case benchmark, MacroBench, sampled from real programs. It claims the large language models it tested translate more macros but make mistakes on 8% to 28% of attempts, forcing manual validation of every output. The central result is a two-stage tag team: run MerC first, then let an LLM handle the remainder, which lowers the average failure rate by 32% compared with LLMs alone while translating 51% more cases than MerC alone. If correct, this gives a practical recipe for preserving macro abstractions during C-to-Rust translation instead of losing them to preprocessing.

What carries the argument

The central mechanism is a six-way Venn diagram of the semantics shared by macros and C constructs, formalized as seven inference rules in Figure 2. Each rule names premises phrased as Boolean properties, such as defined globally, no environment capture, no metaprogramming, no address-of or sizeof use, no compile-time-constant requirement, and monomorphic non-void type, and a conclusion that rewrites the macro definition to a static const variable, enum, static inline function, or void function while leaving every call site unchanged. The premises are evaluated by a macro analyzer from prior work that computes these Boolean properties for every abstract-syntax-tree-aligned macro invocation. Because every invocation must satisfy every premise, at most one rule applies to a macro and unsupported macros are left untranslated, which is what underpins the claim that MerC only produces correct translations.

What would settle it

Compile and run, with identical inputs, the original and MerC-translated versions of every MacroBench case and compare behavior, memory layout, and preprocessor conditionals; a single translated macro that behaves differently, or a single macro satisfying all premises of one rule in Figure 2 that MerC refuses to translate or translates incorrectly, would refute the claim that MerC only produces correct translations.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central discovery is that macros can be classified by which C-language semantics they already obey, and that this classification yields a sound translator. MerC's seven rules convert object-like macros to global variables or enums and function-like macros to inline or void functions, but only when the macro is globally defined, does not capture surrounding identifiers, does no token manipulation, is not used with address-of or sizeof, is not required to be a compile-time constant, and has one consistent type. On MacroBench's 398 randomly sampled, statistically significant test cases, MerC translated 50% with zero failures, while three widely used LLMs translated more but failed on 8% to 28% of their attempts. Running MerC first and then asking an LLM to translate only the remaining macros cut the average failure rate by 32% relative to using an LLM alone and increased translations by 51% relative to MerC alone, with about 66% fewer LLM translations requiring hand-validation. The paper also reports that on 23 whole programs, MerC translated 8,211 of 100,711 macro invocations and all programs still compiled and passed their test suites.

Load-bearing premise

The load-bearing premise is that the semantic properties supplied by the pre-existing macro analyzer are complete and correct; those properties are validated only by the analyzer's own 95-test suite, so if a property is wrong for some invocation, MerC's promise of zero incorrect translations fails.

Editorial extensions

If this is right

  • For the roughly half of macros MerC supports, developers can translate them with zero manual validation, because MerC produced no incorrect translations across MacroBench.
  • Tag teams using MerC first cut the number of LLM translations needing hand-validation by about 66% on average compared with delegating all macros to an LLM.
  • Because MerC preserves call-site syntax, downstream C-to-Rust translators can convert MerC's inline functions into Rust inline functions or macros, preserving both abstraction and performance.
  • On whole programs, MerC translated 8,211 of 100,711 macro invocations across 23 programs and all programs still compiled and passed their test suites, suggesting the zero-failure result is not limited to the benchmark.
  • Few-shot and chain-of-thought prompting reduced failures for the reasoning-focused LLM but also made it skip more cases, so prompting alone does not close the gap the tag team addresses.

Reading between the lines

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

  • Editorial extension: A direct test of the rules' completeness would run MerC to a fixpoint on the 23 whole programs, peeling nested macros, and measure how far the 8% translation rate rises; the paper notes this is possible but does not quantify it.
  • Editorial extension: The 30 macros no tool translated are mostly token-pasting or metaprogramming macros, so a targeted rule or prompt for those patterns would close most of the remaining gap without weakening MerC's conservative premises.
  • Editorial extension: The tag-team division, a sound narrow tool first and an unsound broad tool on the residue, is a general recipe for other code-translation tasks; the paper's measured 32% failure-rate reduction quantifies the benefit in this setting.
  • Editorial extension: Because MacroBench ships per-macro single files, the same evaluation can be rerun as LLMs improve, making the paper's LLM-versus-MerC comparison a moving baseline rather than a fixed result.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper presents MerC, a rule-based macro-to-C translator whose seven inference rules (Figure 2) convert object-like macros to global variables or enums and function-like macros to functions, using semantic Boolean properties computed by the Maki analyzer. It also introduces MacroBench, a statistically sampled benchmark of 398 macro test cases drawn from 23 real-world C programs, and compares MerC against three LLMs (GPT-4o, Claude 3.5 Sonnet, o1 Preview). The reported results are that MerC translates 50% of MacroBench with zero failures, LLMs translate 61-88% with 8-28% failure rates, and a MerC-first tag team lowers the average failure rate by 32% while increasing translations by 51% over MerC alone.

Significance. MacroBench and the empirical comparison are useful contributions: the benchmark was sampled independently of MerC, correctness labels were checked with GCC and by manual review, and whole-program compile/test results are reported for all 23 programs. The tag-team insight is actionable, since a fast rule-based front end reduces the number of LLM outputs that need hand validation. The formal rule set is not yet sound as written, however: at least two rules in Figure 2 admit macros whose translations change callsite types or are not strictly conforming C. The paper's strongest claim that MerC 'only produces correct translations' therefore needs repair before the headline results can be accepted as stated.

major comments (3)
  1. [Section 2.3, Figure 2 (Rule I)] Rule I's conclusion `static const type name = body;` is incorrect when `type` is a pointer type. In C, `static const char *name` declares a pointer to const char, not a const pointer to char. For example, if `#define STR "hello"` is used at a callsite `char *s = STR;`, the original macro expansion is valid, but the translated declaration `static const char *STR = "hello";` makes `STR` have type `const char *`, so `char *s = STR;` violates C11 6.5.16.1 by discarding the `const` qualifier from the pointed-to type. Premise 12 only excludes `void`; no premise excludes pointer types, and pointer-valued constant expressions otherwise satisfy Rule I's premises. Thus the rule does not preserve callsite types for pointer-typed constant macros, and the Section 2.5 claim that MerC's rules guarantee correct translations is not supported. The rule needs a correct declarator form such as `static type const name = body;` (e.g., `static char *const STR = ...;`) or an added premise excluding pointer types.
  2. [Section 2.4, Figure 2 (Rule II)] Rule II's translation to `enum { name = body; }` is not strictly conforming C for all macros admitted by its premises. Premise 23 checks only `SizeOf(type) <= SizeOf(int)`, but C11 6.7.2.2 requires the expression defining an enumeration constant to have a value representable as an `int`. A macro such as `#define FLAG 0x80000000u` satisfies Premises 19, 22, and 23 (type `unsigned int`, integer constant expression, size 4 on a typical platform), yet `enum { FLAG = 0x80000000u };` is not strictly conforming C, and in C11 an enumeration constant has type `int`, changing `FLAG`'s type from `unsigned int`. Rule II needs a value-range premise or an explicit statement of the C dialect and compiler extensions it relies on.
  3. [Section 2.5] The correctness argument treats Maki's Boolean properties in Table 1 as premises whose soundness is assumed. Section 2.5 cites only Maki's own 95-test suite as evidence for these properties, and no theorem relates each property to the C and preprocessor semantics it is supposed to capture. Because a false positive in any property, such as `CapturesEnvironment` or `IsConstExpr`, would make a rule fire on a macro whose translation changes behavior, the universal claim that MerC 'only produces correct translations' is stronger than the evidence provided. I would like a formal statement of what each predicate over-approximates or under-approximates, or an independent validation of the predicates against a manually labeled corpus of macro invocations.
minor comments (5)
  1. [Table 1 and Figure 2] The helper names contain typos: `AddressReqired`, `SizeReqired`, and `ConstExprReqired` should be spelled `AddressRequired`, `SizeRequired`, and `ConstExprRequired`.
  2. [Figures 5 and 6] The stacked-bar figures are hard to decode; the caption of Figure 5 should define explicitly, for each tool, how the three categories ('Correct formal translations', 'Hand-validated LLM translations', 'Incorrect LLM translations') relate to the totals for the 'Alone' and 'With MerC' conditions, and Figure 6 should state that MerC's 37 seconds is rounded to 1 minute.
  3. [Section 5.2] The temperature settings are described only as the Copilot defaults; for reproducibility, the actual temperature values (or the exact Copilot versions whose defaults were used) should be reported.
  4. [Section 5.6] The statement that the tag team has an 'average failure rate 32% lower' should specify whether the reduction is relative or absolute, and should give the baseline average over which the 32% is computed, since the individual LLM failure rates vary from 8% to 28%.
  5. [Section 4.2] The description of recursive context inclusion is informal; a precise algorithm or a reference to the artifact's slicing code would make the benchmark construction fully reproducible.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; MerC's formal rules and empirical claims are self-contained against an independently constructed benchmark and manual validation.

full rationale

I find no circular derivation. MerC's translation rules in Figure 2 are stated as formal specifications with explicit premises; translatability is not defined in terms of the evaluation outcome. The correctness claim is supported by Section 5's semi-automatic validation (GCC compile checks plus double manual labeling) on MacroBench, which Section 6.1 states was created after MerC and by a separate author, so the benchmark is not an output of the rule system. The main dependency on prior work is Maki [54], a separate macro analyzer from the same research group; Maki's Boolean properties are external inputs to MerC and are accompanied by a 95-test suite, and the paper does not define MerC's correctness as merely 'whatever Maki returns.' Thus no prediction reduces by construction to its input, and no uniqueness theorem or ansatz is imported from the authors' prior work to force MerC's design. The pointer-const type concern about Rule I and any residual doubt about Maki's soundness are correctness or validity risks, not instances of circular derivation, and are outside the scope of this circularity analysis.

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

The main premises are Maki's semantic properties, the sufficiency of the rule premises, the fidelity of macro slicing in MacroBench, and the accuracy of manual failure labels. No free parameters are fitted: the benchmark size is chosen for statistical confidence and stratification follows program sizes. No invented entities are introduced.

assumptions (4)
  • domain assumption Maki's Boolean semantic properties are correct and complete for all macro invocations it analyzes.
    Every premise in Figure 2 is computed using Maki. Section 2.5 cites Maki's 95-test suite, but no formal proof or independent verification is given; Maki is by two of this paper's authors.
  • ad hoc to paper The premises of Rules I-IV in Figure 2 are sufficient for semantics-preserving translation.
    Section 2.5 asserts correctness of the rules without derivation: the rules are designed from studying prior correct and incorrect translators, not proven. A counterexample with pointer-typed constant macros suggests Rule I's const placement is unsound.
  • domain assumption Hand-slicing macros into MacroBench test cases preserves the macros' original semantics (Section 4.2).
    The benchmark is the basis for all attempt and failure rates. If slicing changes semantics, the numbers do not reflect real-world macro translation.
  • domain assumption Manual classification of the 20% of translations that compile but behave differently is accurate (Sections 5.2 and 6.1).
    Students trained by a co-author labeled failures; no inter-rater agreement metric is reported, though a co-author re-checked everything.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Translation Tag Team: Formal Rules and LLMs Translate More Macros Together than Apart." pith.science (2026). https://pith.science/paper/NLNNJ6GJ

@misc{pith2026260806705,
  author       = {Pith},
  title        = {Pith review of: Translation Tag Team: Formal Rules and LLMs Translate More Macros Together than Apart},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NLNNJ6GJ}},
  note         = {Machine review of arXiv:2608.06705}
}
read the original abstract

Modern critical software infrastructure is largely written in C. Since C lacks memory safety, researchers are investigating automatic translation of C to safer languages like Rust. But real-world C software consists of more than just C code, often using named code fragments called macros which are not part of the C language proper. State-of-the-art techniques avoid translating macros by preprocessing C code first before translating it. But this approach produces translations that are dissimilar to the original C code, because preprocessing inlines all macro definitions. To preserve macro usage in translated code, we study the language features that macros and C share and distill them into the first formally-specified translator, MerC. To evaluate MerC, we introduce the first macro translation benchmark, MacroBench, with test cases based on macros randomly sampled from real-world C programs. We find that MerC supports 50% of MacroBench's macro test cases. We also use MacroBench to evaluate how effective large language models (LLMs) are at performing the previously-unstudied task of macro translation. LLMs translate 22% to 77% more of MacroBench than MerC, but with 8% and 28% of these translations being incorrect translations requiring additional validation by developers. In contrast, MerC only produces correct translations. Our key insight is that running MerC first then using LLMs on the remainder reaps greater benefits than using either technique alone. This tag team approach has an average failure rate 32% lower than that of LLMs, while also translating an average of 51% more test cases than MerC.

Figures

Figures reproduced from arXiv: 2608.06705 by the authors.

Figure 1
Figure 1. Semantics available to C and macro constructs. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Formal rules for MerC’s translation of macros to C code. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. MerC architecture diagram. Circles are data. Dark [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Attempt rates, failure rates, and translation times for LLMs and MerC when translating MacroBench’s test cases. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Types of translations performed by MerC, LLMs, [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Total translation times for MerC, LLMs, and tag [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Comparison of the number of o1 Preview’s failed [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

80 extracted references · 57 canonical work pages

  1. [1]

    Loubna Ben Allal, Raymond Li, Denis Kocetkov, Chenghao Mou, Christopher Akiki, Carlos Munoz Ferrandis, Niklas Muennighoff, Mayank Mishra, Alex Gu, Manan Dey, Logesh Kumar Umapathi, Carolyn Jane Anderson, Yangtian Zi, Joel Lamy Poirier, Hailey Schoelkopf, Sergey Troshin, Dmitry Abulkhanov, Manuel Romero, Michael Lappert, Francesco De Toni, Bernardo García ...

  2. [2]

    Greg Badros and David Notkin. 2000. A Framework for Preprocessor-Aware C Source Code Analyses.Software Prac. Experience30 (July 2000). doi:10.1002/ (SICI)1097-024X(20000710)30:8<907::AID-SPE324>3.3.CO;2-9

    work page 2000

  3. [3]

    Brent Pappas, Joseph Zalusky, Zachary Burkett and Paul Gazzillo. 2026. Arti- fact for Translation Tag Team: Formal Rules and LLMs Translate More Macros Together than Apart. https://doi.org/10.5281/zenodo.21798007

    work page doi:10.5281/zenodo.21798007 2026

  4. [4]

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

    2020

  5. [5]

    Elliot Chance. 2021. c2go. https://github.com/elliotchance/c2go

    work page 2021

  6. [6]

    CISA. 2023. The Case for Memory Safe Roadmaps. https://www.cisa.gov/sites/ default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf

    work page 2023

  7. [7]

    Correct Computation Inc. 2021. 3C. https://github.com/correctcomputation/ checkedc-clang/

    work page 2021

  8. [8]

    Correct Computation Inc. 2021. 3C. https://github.com/correctcomputation/ checkedc-clang/issues/400

    work page 2021

Show all 80 references
  1. [9]

    Correct Computation Inc. 2021. 3C. https://github.com/correctcomputation/ checkedc-clang/issues/40

    2021

  2. [10]

    Correct Computation Inc. 2021. 3C. https://github.com/correctcomputation/ checkedc-clang/issues/439

    2021

  3. [11]

    Stephen Crane. 2020. Document and (potentially) stabilize –translate-const- macros. https://github.com/immunant/c2rust/issues/304

    2020

  4. [12]

    Stephen Crane. 2023. long double #defines incompatible with –translate-const- macros. https://github.com/immunant/c2rust/issues/829

    2023

  5. [13]

    DARPA. 2024. Translating All C TO Rust (TRACTOR). https://sam.gov/opp/ 1e45d648886b4e9ca91890285af77eb7/view

    2024

  6. [14]

    2021.CppSig: Extracting Type Information for C-Preprocessor Macro Expansions

    Christian Dietrich. 2021.CppSig: Extracting Type Information for C-Preprocessor Macro Expansions. Association for Computing Machinery, New York, NY, USA, 62–68. https://doi.org/10.1145/3477113.3487268

    2021

  7. [15]

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

    2021 doi

  8. [16]

    Ernst, Greg J

    Michael D. Ernst, Greg J. Badros, and David Notkin. 2002. An Empirical Analysis of C Preprocessor Use.IEEE Trans. Softw. Eng.28, 12 (Dec. 2002), 1146–1170. doi:10.1109/TSE.2002.1158288

    2002 arXiv

  9. [17]

    Mark Chen et al. 2021. Evaluating Large Language Models Trained on Code. arXiv:2107.03374 [cs.LG] https://arxiv.org/abs/2107.03374

    2021 arXiv

  10. [18]

    Raymond Li et al. 2023. StarCoder: may the source be with you! arXiv:2305.06161 [cs.CL] https://arxiv.org/abs/2305.06161

    2023 arXiv

  11. [19]

    Dwayne Forde. 2024. Working with AI (Part 2): Code Conversion. https://blog. withmantle.com/code-conversion-using-ai/

    2024

  12. [20]

    Free Software Foundation, Inc. 2025. Concatenation (The C Preprocessor). https: //gcc.gnu.org/onlinedocs/cpp/Concatenation.html

    2025

  13. [21]

    Free Software Foundation, Inc. 2025. Macros (The C Preprocessor). https://gcc. gnu.org/onlinedocs/cpp/Macros.html

    2025

  14. [22]

    Free Software Foundation, Inc. 2025. Stringizing (The C Preprocessor). https: //gcc.gnu.org/onlinedocs/cpp/Stringizing.html

    2025

  15. [23]

    Free Software Foundation, Inc. 2025. Stringizing (The C Preprocessor). https: //gcc.gnu.org/onlinedocs/cpp/Self-Referential-Macros.html

    2025

  16. [24]

    Vrunda Gadesha. 2024. What is few shot prompting? https://www.ibm.com/ think/topics/few-shot-prompting

    2024

  17. [25]

    Vrunda Gadesha and Eda Kavlakoglu. 2024. What is chain of thoughts (CoT)? https://www.ibm.com/think/topics/chain-of-thoughts

    2024

  18. [26]

    2017.Performance Measurement of C Software Product Lines

    Florian Garbe. 2017.Performance Measurement of C Software Product Lines. Master’s thesis. University of Passau. https://www.se.cs.uni-saarland.de/theses/ FlorianGarbeMA.pdf

    2017

  19. [27]

    Paul Gazzillo and Robert Grimm. 2012. SuperC: Parsing All of C by Taming the Preprocessor.SIGPLAN Not.47, 6 (June 2012), 323–334. doi:10.1145/2345156. 2254103

    2012 doi

  20. [28]

    GitHub. 2024. Bringing developer choice to Copilot with Anthropic’s Claude 3.5 Sonnet, Google’s Gemini 1.5 Pro, and OpenAI’s o1-preview. https://github.blog/news-insights/product-news/bringing-developer-choice- to-copilot/#anthropics-claude-3-5-sonnet

    2024

  21. [29]

    GitHub. 2024. Claude 3.5 Sonnet is now available in public pre- view. https://github.blog/changelog/2024-11-01-claude-3-5-sonnet-is-now- available-to-all-copilot-users-in-public-preview/

    2024

  22. [30]

    GitHub. 2025. GitHub Copilot. https://marketplace.visualstudio.com/items? itemName=GitHub.copilot

    2025

  23. [31]

    GitHub. 2025. Prototyping with AI models. https://docs.github.com/en/github- models/prototyping-with-ai-models#rate-limits

    2025

  24. [32]

    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

    2024 doi

  25. [33]

    Immunant. 2018. c2rust. https://github.com/immunant/c2rust/issues/16

    2018

  26. [34]

    Immunant inc. 2023. c2rust. https://github.com/immunant/c2rust

    2023

  27. [35]

    Immunant inc. 2023. c2rust. https://github.com/immunant/c2rust/tree/ 3e0183e4d56f9d4d003f1ea2e9a814648debf307

    2023

  28. [36]

    2024.Information technology – Programming languages – C

    ISO/IEC JTC 1. 2024.Information technology – Programming languages – C. Standard 9899:1990. International Organization for Standardization. https:// www.iso.org/standard/17782.html

    2024

  29. [37]

    2024.Information technology – Programming languages – C

    JTC1/SC22/WG14. 2024.Information technology – Programming languages – C. Standard 9899:2024. International Organization for Standardization. https: //www.iso.org/standard/82075.html

    2024

  30. [38]

    Giarrusso, Tillmann Rendel, Sebastian Erdweg, Klaus Ostermann, and Thorsten Berger

    Christian Kästner, Paolo G. Giarrusso, Tillmann Rendel, Sebastian Erdweg, Klaus Ostermann, and Thorsten Berger. 2011. Variability-Aware Parsing in the Presence of Lexical Macros and Conditional Compilation. InProceedings of the 2011 ACM International Conference on Object Orien...

    2011

  31. [39]

    KratosLab. 2025. Prompt Engineering for OpenAI’s O1 and O3-mini Reason- ing Models. https://kratoslab.com/prompt-engineering-for-openais-o1-and-o3- mini-reasoning-models/

    2025

  32. [40]

    Aditya Kumar, Andrew Sutton, and Bjarne Stroustrup. 2012. Rejuvenating C++ programs through demacrofication. In2012 28th IEEE International Conference on Software Maintenance (ICSM). Institute of Electrical and Electronics Engineers, 445 Hoes Ln, Piscataway, NJ 08854, United S...

    2012 doi

  33. [41]

    Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Cohen, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas Vasilache, and Olek- sandr Zinenko. 2021. MLIR: scaling compiler infrastructure for domain spe- cific computation. InProceedings of the 2021 IEEE/AC...

    2021

  34. [42]

    Alex Lazar and Jean Melo. 2017. C Reconfigurator. https://github.com/itu- square/c-reconfigurator

    2017

  35. [43]

    Yinheng Li. 2023. A Practical Survey on Zero-shot Prompt Design for In-context Learning. InProceedings of the Conference Recent Advances in Natural Language Processing - Large Language Models for Natural Language Processings (RANLP). INCOMA Ltd., Shoumen, BULGARIA, Shoumen, Bu...

    2023

  36. [44]

    Bill McCloskey and Eric Brewer. 2005. ASTEC: A New Approach to Refactoring C. SIGSOFT Softw. Eng. Notes30, 5 (Sept. 2005), 21–30. doi:10.1145/1095430.1081712

    2005

  37. [45]

    Mennie and Charles L

    Christopher A. Mennie and Charles L. A. Clarke. 2004. Giving meaning to macros. Proceedings. 12th IEEE International Workshop on Program Comprehension, 2004. 12 (2004), 79–85. https://api.semanticscholar.org/CorpusID:26483462

    2004

  38. [46]

    Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. 2023. CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. arXiv:2203.13474 [cs.LG] https://arxiv.org/abs/2203.13474 Translation Tag Team: ...

    2023 arXiv

  39. [47]

    OpenAI. 2024. Hello GPT-4o. https://openai.com/index/hello-gpt-4o/

    2024

  40. [48]

    OpenAI. 2024. Introducing OpenAI o1-preview. https://openai.com/index/ introducing-openai-o1-preview/

    2024

  41. [49]

    OpenAI. 2024. Learning to reason with LLMs. https://openai.com/index/learning- to-reason-with-llms/

    2024

  42. [50]

    OpenAI. 2024. Overview - OpenAI API. https://platform.openai.com/docs/ overview

    2024

  43. [51]

    Yoann Padioleau. 2009. Parsing C/C++ Code without Pre-Processing. InPro- ceedings of the 18th International Conference on Compiler Construction: Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2009(York, UK)(CC ’09). Springer-Verlag, Be...

    2009 doi

  44. [52]

    Rangeet Pan, Ali Reza Ibrahimzada, Rahul Krishna, Divya Sankar, Lam- bert Pouguem Wassi, Michele Merler, Boris Sobolev, Raju Pavuluri, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Code....

    2024

  45. [53]

    Brent Pappas. 2023. Holy Macroni! A recipe for progressive language en- hancement. https://blog.trailofbits.com/2023/09/11/holy-macroni-a-recipe-for- progressive-language-enhancement/

    2023

  46. [54]

    Brent Pappas and Paul Gazzillo. 2024. Semantic Analysis of Macro Usage for Portability. In2024 IEEE/ACM 46th International Conference on Software Engineer- ing (ICSE). Association for Computing Machinery, 1601 Broadway, 10th Floor New York, NY 10019-7434, 229–240. doi:10.1145/...

    2024

  47. [55]

    Brent Pappas, Joseph Zalusky, Zachary Burkett, and Donovan Reynolds. 2026. Macros. https://github.com/appleseedlab/maki. [Accessed 07-09-2026]

    2026

  48. [56]

    Zachary Patterson, Zenong Zhang, Brent Pappas, Shiyi Wei, and Paul Gazzillo

  49. [57]

    Augustin Popa. 2018. Convert Macros to Constexpr. https://devblogs.microsoft. com/cppblog/convert-macros-to-constexpr/

    2018

  50. [58]

    Post and C

    H. Post and C. Sinz. 2008. Configuration Lifting: Verification meets Software Configuration. InProceedings of the 23rd IEEE/ACM International Conference on Automated Software Engineering (ASE ’08). IEEE Computer Society, USA, 347–350. doi:10.1109/ASE.2008.45

    2008 doi

  51. [59]

    Sanjeev Reddy. 2018. Auto refactor of a macro followed by a com- ment to a constexpr put the semicolon after the comment. https: //developercommunity.visualstudio.com/t/auto-refactor-of-a-macro-followed- by-a-comment-to/354205

    2018

  52. [60]

    Remmirad. 2023. Problematic macro translation with –translate-const-macros. https://github.com/immunant/c2rust/issues/803

    2023

  53. [61]

    Rust Team. 2026. Code Generation Attributes. https://doc.rust-lang.org/ reference/attributes/codegen.html#the-inline-attribute. [Accessed 07-09-2026]

    2026

  54. [62]

    Rust Team. 2026. Macros. https://doc.rust-lang.org/book/ch20-05-macros.html. [Accessed 07-09-2026]

    2026

  55. [63]

    Rogers, Inna Goncearenco, Giuseppe Sarli, Igor Galynker, Denis Peskoff, Marine Carpuat, Jules White, Shyamal Anad- kat, Alexander Hoyle, and Philip Resnik

    Sander Schulhoff, Michael Ilie, Nishant Balepur, Konstantine Kahadze, Amanda Liu, Chenglei Si, Yinheng Li, Aayush Gupta, HyoJung Han, Sevien Schul- hoff, Pranav Sandeep Dulepet, Saurav Vidyadhara, Dayeon Ki, Sweta Agrawal, Chau Pham, Gerson Kroiz, Feileen Li, Hudson Tao, Ashay...

    2025 arXiv

  56. [64]

    Jamey Sharp. 2017. Corrode. https://github.com/jameysharp/corrode/tree/ 84c6d7b5dedb32093ada9420ebd9f020828af6c5

    2017

  57. [65]

    Momoko Shiraishi and Takahiro Shinagawa. 2024. Context-aware Code Segmentation for C-to-Rust Translation using Large Language Models. arXiv:2409.10506 [cs.SE] https://arxiv.org/abs/2409.10506

    2024

  58. [66]

    Diomidis Spinellis. 2003. Global Analysis and Transformations in Preprocessed Languages.IEEE Trans. Softw. Eng.29, 11 (Nov. 2003), 1019–1030. doi:10.1109/ TSE.2003.1245303

    2003 arXiv

  59. [67]

    Vrunda Gadesha Meredith Syed. 2025. What is zero-shot prompting? https: //www.ibm.com/think/topics/zero-shot-prompting

    2025

  60. [68]

    The Linux Kernel. 2024. Linux kernel coding style. https://github.com/torvalds/ linux/blob/master/Documentation/process/coding-style.rst#12-macros-enums- and-rtl. Section 12, Macros, Enums and RTL

    2024

  61. [69]

    Trail of Bits. 2023. Macroni. https://github.com/trailofbits/macroni

    2023

  62. [70]

    Alexander von Rhein, Thomas Thüm, Ina Schaefer, Jörg Liebig, and Sven Apel

  63. [71]

    vs-code-engineering. 2025. Temperature Setting·Issue #258748·microsoft- /vscode — github.com. https://github.com/microsoft/vscode/issues/258748# issuecomment-3662247602. [Accessed 19-06-2026]

    2025

  64. [72]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven C. H. Hoi. 2021. CodeT5: Identifier-aware Unified Pre-trained Encoder-Decoder Models for Code Un- derstanding and Generation. InProceedings of the 2021 Conference on Empir- ical Methods in Natural Language Processing, Marie-Franci...

    2021 doi

  65. [73]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, brian ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. InAdvances in Neural Information Processing Systems, S. Koyejo, S. Mohamed, A. Agarwal...

    2022

  66. [74]

    White House Office of the National Cyber Director. 2024. Back to the Building Blocks: A Path Toward Secure and Measurable Soft- ware. https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD- Technical-Report.pdf

    2024

  67. [75]

    Xu, Uri Alon, Graham Neubig, and Vincent Josua Hellendoorn

    Frank F. Xu, Uri Alon, Graham Neubig, and Vincent Josua Hellendoorn. 2022. A systematic evaluation of large language models of code. InProceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming(San Diego, CA, USA)(MAPS 2022). Association for Computing Ma...

    2022

  68. [76]

    Qinkai Zheng, Xiao Xia, Xu Zou, Yuxiao Dong, Shan Wang, Yufei Xue, Lei Shen, Zihan Wang, Andi Wang, Yang Li, Teng Su, Zhilin Yang, and Jie Tang

  69. [80]

    InProceedings of the 29th ACM SIGKDD Con- ference on Knowledge Discovery and Data Mining(Long Beach, CA, USA)(KDD ’23)

    CodeGeeX: A Pre-Trained Model for Code Generation with Multilingual Benchmarking on HumanEval-X. InProceedings of the 29th ACM SIGKDD Con- ference on Knowledge Discovery and Data Mining(Long Beach, CA, USA)(KDD ’23). Association for Computing Machinery, New York, NY, USA, 5673...

  70. [2016]

    Variability encoding: From compile-time to load-time variability.Journal of Logical and Algebraic Methods in Programming85, 1, Part 2 (2016), 125–145. doi:10. 1016/j.jlamp.2015.06.007 Formal Methods for Software Product Line Engineering

    2016

  71. [2022]

    InProceedings of the 44th International Conference on Software Engineering (Pittsburgh, Pennsylvania)(ICSE ’22)

    SugarC: scalable desugaring of real-world preprocessor usage into pure C. InProceedings of the 44th International Conference on Software Engineering (Pittsburgh, Pennsylvania)(ICSE ’22). Association for Computing Machinery, New York, NY, USA, 12 pages. doi:10.1145/3510003.3512763

  72. [2023]

    SantaCoder: don’t reach for the stars! arXiv:2301.03988 [cs.SE] https: //arxiv.org/abs/2301.03988

    arXiv

Pith tools

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