Pith. sign in

REVIEW 2 major objections 5 minor 62 references

CXXCrafter: An LLM-Based Agent for Automated C/C++ Open Source Software Building

T0 review · 2 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read CXXCrafter, an LLM-based agent, automatically builds 587 of 752 popular C/C++ open-source projects in the paper's evaluation.

desk verdict A valuable first LLM-agent system for C/C++ build automation with a plausible 78% success rate, but the success metric needs an externally audited artifact check before the number is fully trustable. read the letter →

arxiv 2505.21069 v1 pith:3FHVPOBC submitted 2025-05-27 cs.SE

Zhengmin Yu , Yuan Zhang , Ming Wen , Yinan Nie , Wenhui Zhang , Min Yang This is my paper
classification cs.SE
keywords LLMagentC/C++buildautomationDockerfilegenerationdependencyresolutionfailuretaxonomyopensourcesoftwarelargelanguagemodels
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

An LLM-driven agent can automate most C/C++ project builds. The paper reports that CXXCrafter successfully builds 587 of 752 projects (78%), compared with 39% for default build commands and 31.65% for a bare GPT-4o prompt, while human experts built 86 of the 100-project subset. The paper first documents why building is hard: 384 errors across 79 projects, costing 153 man-hours, with missing libraries the dominant cause. Its claimed result matters because building C/C++ software from source is the bottleneck for tasks that need compiled binaries or intermediate representations, such as fuzzing, static analysis, and vulnerability reproduction. If the 78% rate holds, an automated agent can prepare the majority of popular repositories for those downstream analyses without manual setup.

What carries the argument

The load-bearing mechanism is the generator-executor feedback loop wrapped around an LLM. The Parser module pre-extracts environment details, dependencies, and build-relevant documentation via retrieval; the Generator turns those into a candidate Dockerfile using structured prompt templates; the Executor runs the Dockerfile in a clean container and returns captured logs. The loop repeats up to ten times, so each error message becomes the prompt for the next patch. A second piece does the verification: an LLM-based discriminator checks both that the Dockerfile contains real build instructions and that the execution log shows compiling progress, which is what lets the paper count genuine builds rather than silent no-op failures.

What would settle it

Rebuild the released Dockerfiles for the claimed successful projects in clean containers and run each produced binary through the project's own tests plus an independent diff against manual builds; the paper's unit-test check covers only 24 of 75 Top100 projects, so the remaining builds are the open question.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that the obstacle to automated C/C++ building is not raw compilation but the decisions around it: which build system to trust, which dependencies to install, which OS version to choose, and how to tell a real build from a silent no-op. CXXCrafter addresses this with a three-module agent loop. A Parser extracts environment details, dependency lists, and build-relevant documentation; a Generator writes a Dockerfile from nested prompt templates; an Executor runs the Dockerfile in a clean container and returns error logs. The Generator and Executor iterate up to ten times, so each failure message becomes the input for the next repair. The paper reports 75/100 and 512/652 successes on its two datasets, three projects that manual builders could not finish, artifact equivalence with manual builds via diff, and a cost of $0.41 and 875 seconds per successful build.

Load-bearing premise

The 78% rate rests on the paper's own checklist for success: build commands present and logs showing the compiler actually ran, rather than on a fully described independent check of the produced binaries.

Editorial extensions

If this is right

  • Downstream program-analysis pipelines can treat building the project as an automatable step, enabling fuzzing, vulnerability reproduction, and IR-based static analysis across large open-source corpora.
  • The reported $0.41 and roughly 15 minutes per successful build make the approach affordable to run at corpus scale rather than only on hand-picked projects.
  • Success across old commits (81/100) and consecutive commits (96/100) suggests the agent adapts to version drift instead of memorizing a single snapshot.
  • The Java adaptation experiment (57/76, 75%) indicates the agent architecture is not C/C++-specific and may transfer to other language ecosystems.

Reading between the lines

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

  • The 587 generated Dockerfiles themselves form a reusable corpus: they could be mined as retrieval examples for unseen repositories or distilled into a cheaper builder, which the paper does not do.
  • If the success rate holds for less popular projects, the bottleneck shifts from whether a build is possible to whether the produced artifact is trustworthy, so independent artifact verification would become the limiting step.
  • A natural next test the paper does not run is using the loop in pull-request CI, where the ten-step budget and clean-container model fit but the time and cost constraints are stricter.
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 / 5 minor

Summary. The paper first reports an empirical study of building 100 popular C/C++ projects: only 21 succeed with default build commands, and human experts reach 86/100 after classifying 384 build errors. It then presents CXXCrafter, an LLM-based agent with parser, generator, and executor modules that produces Dockerfiles and iteratively repairs them from build logs. The evaluation claims 587/752 successful builds (78.10%), split as 75/100 on Top100 and 512/652 on Awesome-CPP, outperforming default build commands (39.01%) and bare LLMs (19.81--38.43%). The paper also reports ablations, multiple LLM backends, a case study of three projects built by CXXCrafter but not manually, cost and efficiency data, cross-version experiments, and a Java migration result.

Significance. If the headline measurement is correct, this is a valuable contribution: it is among the first LLM-agent systems for C/C++ build automation, with a large 752-project evaluation, four baselines, four LLM backends, parser and interaction ablations, unit-test spot checks, cost data, and a released implementation. The error taxonomy of 384 errors across 79 projects is itself a useful empirical resource. The main caveat is that the central 78% number rests on success criteria applied by the authors and validated by an underspecified artifact-diff claim, so the paper's principal claim is not yet externally verifiable as written.

major comments (2)
  1. [Section 5, Metrics of Success and Section 6] The headline claim of 587/752 successful builds is defined by criteria applied by the authors: static inspection of whether the Dockerfile contains build commands for primary components, plus dynamic inspection of whether logs show compilation progress and no errors. The only checks against actual build outcomes are unit tests run on 24 of the 75 Top100 successes (22 passing) and a single sentence stating that a diff tool found automated and manual artifacts completely consistent. The diff procedure is not specified: what artifacts were compared, at what granularity, what tolerance was allowed for nondeterministic build metadata, and whether the primary executable was confirmed present. Because none of the 512 Awesome-CPP successes receive artifact-level validation, the 78% rate is not externally verifiable from the paper. The authors should describe the diff methodology in detail, release per-project Dockerfiles and logs (or a well-defined sample), and ideally have an independent party re-judge a random sample under the stated criteria.
  2. [Section 4.5 and Section 5] The prompts and the LLM discriminator criteria were refined through iterative experimentation on the Top100 dataset, and Top100 is also one of the two evaluation datasets, yielding the 75/100 result and the near-manual comparison (72 overlap, 3 CXXCrafter-only, 14 manual-only). This makes the abstract's claim that CXXCrafter nearly matches manual performance an in-sample measurement. The Awesome-CPP dataset mitigates the concern for the overall 78% rate because it is external, but the paper should either report a holdout split or quantify how many prompt/criteria revisions were made after seeing Top100 results, so readers can assess the degree of adaptation.
minor comments (5)
  1. [Section 4.4] The discriminator validation paragraph reports that 249 of 400 build processes were classified as successful and that all 249 were manually verified as correct, but it does not report how many of the remaining 151 processes were true failures or whether the discriminator ever misclassified a failed build as successful; the claim that the discriminator is effective is therefore incomplete.
  2. [Section 5.1, Table 5] The text says bare LLMs achieve '23 and 17 successful builds' on Top100, but Table 5 lists three bare-LLM rows with 23, 25, and 17 Top100 builds; the DeepSeek-v3 value is omitted from the sentence and should be aligned.
  3. [Figure 5] The figure legend is truncated in the manuscript ('CXXCrafter-w…[1]') and the reader must rely on the caption note to identify CXXCrafter-w/o-Interaction; the legend and labels should be made fully readable.
  4. [Section 6, Building Different Software Versions] The description of the version-diversity experiment is unclear: 20 projects and 5 commits each cannot literally cover 'their entire repository commit histories,' and it is not stated whether the 20 projects come from Top100 or Awesome-CPP or how the commits were sampled.
  5. [Section 7, Threats to Validity] The statement that 'the authors have rich experiences in C/C++ related researches' and therefore construct-validity threats are limited is an assertion rather than an analysis; the paper should either provide a concrete construct-validity discussion or remove this sentence.

Circularity Check

1 steps flagged · score 3.0 of 10

Top100 is used both to refine the prompts and select the LLM and then reported as an evaluation set, mildly inflating the Top100 column; the Awesome-CPP majority keeps the headline 78% largely independent.

  1. fitted input called prediction [Section 4.5 (Prompt Design) and Section 5.1 (Overall Effectiveness Evaluation, Table 5)]
    "These prompts, developed based on expert knowledge and refined through iterative experimentation, incorporate strategies such as nested prompt templates and RAG to address task complexity. ... For CXXCrafter, the default dynamic interaction step limit is set to 10, with GPT-4o serving as the core LLM due to its superior performance in trials."

    The prompt templates and the default LLM are explicitly refined or selected using the Top100 dataset, and Top100 is then reported as the evaluation result (75/100 in Table 5). Section 4.5 states the prompts were 'refined through iterative experimentation,' Section 5.1 says GPT-4o was chosen 'due to its superior performance in trials,' and the manual Top100 study in Section 3 informed the prompt templates. The Top100 success count is therefore an in-sample measurement of a configuration tuned on that same set, not an out-of-sample prediction. The Awesome-CPP subset (512/652) was not used for refinement, so the headline 78% is only partially affected.

full rationale

The derivation chain is mostly self-contained. The empirical study (Section 3) is an observational analysis, the system design is described concretely, and the main effectiveness claim (587/752, 78.10%) is dominated by the Awesome-CPP subset (512/652), which was external to the design and prompt-tuning process. The cross-version experiment (81/100) and Java migration (57/76) provide additional independent grounding. I found one genuine circular element: Section 4.5 states the prompts were 'refined through iterative experimentation,' and Section 5.1 selects GPT-4o 'due to its superior performance in trials,' while the Top100 dataset is then reported as an evaluation result (75/100 in Table 5). This makes the Top100 column an in-sample measurement rather than a prediction. The success criteria being identical to the executor's discriminator criteria is a construct-validity concern, but the paper's artifact diff and unit tests, though under-specified, are an independent check on that predicate for Top100. Since the overall 78% claim rests mainly on Awesome-CPP, the circularity is partial and localized.

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

No new physical or mathematical entities are introduced; the ledger captures hand-tuned hyperparameters and the domain assumptions on which the empirical evaluation rests.

free parameters (3)
  • Maximum dynamic interaction steps = 10 (default)
    Section 4.1 sets the Generator-Executor loop limit to 10; Section 5.2 ablates 0/5/10/20 (22, 69, 75, 74 builds), showing 10 is a hand-chosen operating point that the central result depends on.
  • Log window sizes for discriminator = 50 lines (error failures) and 200 lines (non-error failures)
    Section 4.4: the executor feeds the last 50 or 200 log lines to the LLM discriminator; these constants affect which failures are detected and thus the reported success rate.
  • Default LLM = GPT-4o
    Section 5: GPT-4o is chosen as the default model, yielding 75/100 vs 67 for DeepSeek-v3; the headline 78% is tied to this model choice.
assumptions (4)
  • domain assumption Docker containers provide a clean, reproducible build environment.
    All builds are executed as Dockerfiles (Sections 4.3-4.4); if container isolation distorts project environments, success rates would not transfer to real machines.
  • domain assumption The static and dynamic success criteria accurately identify genuine builds.
    Section 5 Metrics of Success defines success; the whole evaluation is filtered through these criteria.
  • domain assumption LLMs store sufficient implicit C/C++ build knowledge to generate and repair build scripts.
    Motivates the Generator (Sections 4.1, 4.3) and the LLM discriminator (Section 4.4).
  • domain assumption The selected 100 and 652 projects are representative of C/C++ open-source projects.
    Section 3 dataset selection; Section 7 acknowledges popular-project bias, so generality beyond popular projects is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CXXCrafter: An LLM-Based Agent for Automated C/C++ Open Source Software Building." pith.science (2026). https://pith.science/paper/3FHVPOBC

@misc{pith2026250521069,
  author       = {Pith},
  title        = {Pith review of: CXXCrafter: An LLM-Based Agent for Automated C/C++ Open Source Software Building},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3FHVPOBC}},
  note         = {Machine review of arXiv:2505.21069}
}
read the original abstract

Project building is pivotal to support various program analysis tasks, such as generating intermediate rep- resentation code for static analysis and preparing binary code for vulnerability reproduction. However, automating the building process for C/C++ projects is a highly complex endeavor, involving tremendous technical challenges, such as intricate dependency management, diverse build systems, varied toolchains, and multifaceted error handling mechanisms. Consequently, building C/C++ projects often proves to be difficult in practice, hindering the progress of downstream applications. Unfortunately, research on facilitating the building of C/C++ projects remains to be inadequate. The emergence of Large Language Models (LLMs) offers promising solutions to automated software building. Trained on extensive corpora, LLMs can help unify diverse build systems through their comprehension capabilities and address complex errors by leveraging tacit knowledge storage. Moreover, LLM-based agents can be systematically designed to dynamically interact with the environment, effectively managing dynamic building issues. Motivated by these opportunities, we first conduct an empirical study to systematically analyze the current challenges in the C/C++ project building process. Particularly, we observe that most popular C/C++ projects encounter an average of five errors when relying solely on the default build systems. Based on our study, we develop an automated build system called CXXCrafter to specifically address the above-mentioned challenges, such as dependency resolution. Our evaluation on open-source software demonstrates that CXXCrafter achieves a success rate of 78% in project building. Specifically, among the Top100 dataset, 72 projects are built successfully by both CXXCrafter and manual efforts, 3 by CXXCrafter only, and 14 manually only. ...

Figures

Figures reproduced from arXiv: 2505.21069 by the authors.

Figure 1
Figure 1. The Statistics of Build Tools used in the Top 100 and Awesome-CPP Datasets (introduced in Section 5). Dataset. For our empirical study, we construct a dataset (hereinafter referred to as Top100) via selecting the top 100 most popular open-source C/C++ projects from GitHub, spanning 10 distinct categories to ensure diversity and comprehensiveness. These categories include foundational projects such as operating syste… view at source ↗
Figure 2
Figure 2. The Overall Framework of CXXCrafter As illustrated in [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗
Figure 3
Figure 3. The Parser Module. It is responsible for automatically extracting and analyzing information such as dependencies, build system information, which is crucial for subsequent build processes. details, including CPU specs, OS, and their versions. This information is crucial for addressing issues discussed in Section 3.2.3, such as installing software for specific architectures or ensuring the correct GPU/CPU driver vers… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Prompt of the Generator Module. The prompts corresponding to numbers 3, 4, and 5 are from the Parser’s results, with blue text indicating dynamically parsed content. 5 Evaluation We implement CXXCrafter in Python, without relying on LLM frameworks like Langchain. Our i…
Figure 5
Figure 5. Figure 5: Number of Successful Builds of CXXCrafter Variants on the Top100 Dataset. 5.3 Case Study (RQ5) Among the Top100 dataset, 72 projects are successfully built manually as well as by CXXCrafter in Section 5.1. Three projects succeed in CXXCrafter but fail in manual builds,…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

62 extracted references · 36 canonical work pages

  1. [1]

    Apache Ant Project. 2024. Apache Ant. https://ant.apache.org/. [Online; accessed 29-Aug-2024]

    work page 2024

  2. [2]

    Apache Maven Project. 2024. Apache Maven. https://maven.apache.org/. [Online; accessed 10-Sep-2024]

    work page 2024

  3. [3]

    Saikat Barua. 2024. Exploring autonomous agents through the lens of large language models: A review.arXiv preprint arXiv:2404.04442(2024)

    arXiv 2024

  4. [4]

    Nicholas Carlini, Florian Tramer, Eric Wallace, Matthew Jagielski, Ariel Herbert-Voss, Katherine Lee, Adam Roberts, Tom Brown, Dawn Song, Ulfar Erlingsson, et al. 2021. Extracting training data from large language models. In30th USENIX Security Symposium (USENIX Security 21). 2633–2650

    work page 2021

  5. [5]

    2024.{PentestGPT}: Evaluating and Harnessing Large Language Models for Automated Penetration Testing

    Gelei Deng, Yi Liu, Víctor Mayoral-Vilches, Peng Liu, Yuekang Li, Yuan Xu, Tianwei Zhang, Yang Liu, Martin Pinzger, and Stefan Rass. 2024.{PentestGPT}: Evaluating and Harnessing Large Language Models for Automated Penetration Testing. In33rd USENIX Security Symposium (USENIX Security 24). 847–864

    work page 2024

  6. [6]

    Alex Halderman

    Zakir Durumeric, Frank Li, James Kasten, Johanna Amann, Jethro Beekman, Mathias Payer, Nicolas Weaver, David Adrian, Vern Paxson, Michael Bailey, and J. Alex Halderman. 2014. The Matter of Heartbleed. InProceedings of the 2014 Conference on Internet Measurement Conference(Vancouver, BC, Canada)(IMC ’14). Association for Computing Machinery, New York, NY, ...

    work page arXiv 2014

  7. [7]

    Faraz Fallahi. 2024. Awesome C++. https://github.com/fffaraz/awesome-cpp. Accessed: 2024-09-11

    work page 2024

  8. [8]

    Chongzhou Fang, Ning Miao, Shaurya Srivastav, Jialin Liu, Ruoyu Zhang, Ruijie Fang, Asmita, Ryan Tsang, Najmeh Nazari, Han Wang, and Houman Homayoun. 2024. Large Language Models for Code Analysis: Do LLMs Really Do Their Job? arXiv:2310.12357 [cs.SE] https://arxiv.org/abs/2310.12357

    arXiv 2024

Show all 62 references
  1. [9]

    2024.GNU Compiler Collection

    Free Software Foundation. 2024.GNU Compiler Collection. Free Software Foundation. https://gcc.gnu.org/ Accessed: 1-Aug-2024

    2024

  2. [10]

    2023.GNU Make: The GNU Make Manual

    Free Software Foundation. 2023.GNU Make: The GNU Make Manual. Free Software Foundation. https://www.gnu. org/software/make/manual/make.html Accessed: 26-Feb-2023

    2023

  3. [11]

    2024.Autotools Introduction

    Free Software Foundation. 2024.Autotools Introduction. Free Software Foundation. https://www.gnu.org/software/ automake/manual/html_node/Autotools-Introduction.html Accessed: 12-Sep-2024

    2024

  4. [12]

    GitHub. 2021. GitHub Copilot: Your AI pair programmer. https://github.com/features/copilot Accessed: 2024-09-13

    2021

  5. [13]

    Gradle, Inc. 2024. Gradle Build Tool. https://gradle.org/. [Online; accessed 9-Sep-2024]

    2024

  6. [14]

    Konstantin Grotov, Sergey Titov, Yaroslav Zharov, and Timofey Bryksin. 2024. Untangling Knots: Leveraging LLM for Error Resolution in Computational Notebooks. arXiv:2405.01559 [cs.SE] https://arxiv.org/abs/2405.01559

    2024 arXiv

  7. [15]

    2021.CppBuild: Large-Scale, Automatic Build System for Open Source C++ Repositories

    Lukas Gygi. 2021.CppBuild: Large-Scale, Automatic Build System for Open Source C++ Repositories. B.S. thesis. ETH Zurich

    2021

  8. [16]

    Foyzul Hassan, Shaikh Mostafa, Edmund SL Lam, and Xiaoyin Wang. 2017. Automatic building of java projects in software repositories: A study on feasibility and challenges. In2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 38–47

    2017

  9. [17]

    Foyzul Hassan, Rodney Rodriguez, and Xiaoyin Wang. 2018. RUDSEA: recommending updates of Dockerfiles via software environment analysis. InProceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering(Montpellier, France)(ASE ’18). Association for ...

    2018

  10. [18]

    Foyzul Hassan and Xiaoyin Wang. 2018. HireBuild: An Automatic Approach to History-Driven Repair of Build Scripts. In2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE). 1078–1089. https://doi.org/10.1145/ 3180155.3180181

    2018

  11. [19]

    Glen Hopkins and Kristjan Kalm. 2023. Classifying complex documents: comparing bespoke solutions to large language models. arXiv:2312.07182 [cs.CL] https://arxiv.org/abs/2312.07182

    2023 arXiv

  12. [20]

    Eric Horton and Chris Parnin. 2019. Dockerizeme: Automatic inference of environment dependencies for python code snippets. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 328–338. Proc. ACM Softw. Eng., Vol. 2, No. FSE, Article FSE116. Publi...

    2019

  13. [21]

    Lars Huning and Elke Pulvermueller. 2021. Automatic Code Generation of Safety Mechanisms in Model-Driven Development.Electronics10, 24 (2021). https://doi.org/10.3390/electronics10243150

    2021 doi

  14. [22]

    2024.CMake: A Cross-Platform Makefile Generator

    Kitware Inc. 2024.CMake: A Cross-Platform Makefile Generator. Kitware Inc. https://cmake.org/ Accessed: 12-Sep-2024

    2024

  15. [23]

    Inc. JFrog. 2024. Conan: C and C++ Open Source Package Manager. https://conan.io/. Accessed: 11-Sep-2024

    2024

  16. [24]

    Xin Jiang, Xiang Li, Wenjia Ma, Xuezhi Fang, Yiqun Yao, Naitong Yu, Xuying Meng, Peng Han, Jing Li, Aixin Sun, and Yequan Wang. 2024. Sketch: A Toolkit for Streamlining LLM Operations. arXiv:2409.03346 [cs.CL] https://arxiv.org/abs/2409.03346

    2024 arXiv

  17. [25]

    Matthew Jin, Syed Shahriar, Michele Tufano, Xin Shi, Shuai Lu, Neel Sundaresan, and Alexey Svyatkovskiy. 2023. Inferfix: End-to-end program repair with llms. InProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Softwa...

    2023

  18. [26]

    Jean Kaddour, Joshua Harris, Maximilian Mozes, Herbie Bradley, Roberta Raileanu, and Robert McHardy. 2023. Challenges and applications of large language models.arXiv preprint arXiv:2307.10169(2023)

    2023 arXiv

  19. [27]

    Cheryl Lee, Chunqiu Steven Xia, Jen-tse Huang, Zhouruixin Zhu, Lingming Zhang, and Michael R Lyu. 2024. A Unified Debugging Approach via LLM-Based Multi-Agent Synergy.arXiv preprint arXiv:2404.17153(2024)

    2024

  20. [28]

    Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, et al. 2023. Agentbench: Evaluating llms as agents.arXiv preprint arXiv:2308.03688(2023)

    2023 arXiv

  21. [29]

    LLVM Project. 2024. The LLVM Compiler Infrastructure Project. https://llvm.org/. [Online; accessed 18-Jun-2024]

    2024

  22. [30]

    Yiling Lou, Zhenpeng Chen, Yanbin Cao, Dan Hao, and Lu Zhang. 2020. Understanding build issue resolution in practice: symptoms and fix patterns. InProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software...

    2020

  23. [31]

    Shuai Lu, Daya Guo, Shuo Ren, Junjie Huang, Alexey Svyatkovskiy, Ambrosio Blanco, Colin Clement, Dawn Drain, Daxin Jiang, Duyu Tang, Ge Li, Lidong Zhou, Linjun Shou, Long Zhou, Michele Tufano, Ming Gong, Ming Zhou, Nan Duan, Neel Sundaresan, Shao Kun Deng, Shengyu Fu, and Shuj...

    2021 arXiv

  24. [32]

    Ruchika Malhotra, Anjali Bansal, and Marouane Kessentini. 2024. A Systematic Literature Review on Maintenance of Software Containers.ACM Comput. Surv.56, 8, Article 193 (apr 2024), 38 pages. https://doi.org/10.1145/3645092

    2024 doi

  25. [33]

    Microsoft

    Inc. Microsoft. 2024. vcpkg: C++ Library Manager for Windows, Linux, and macOS. https://vcpkg.io/. Accessed: 23-Aug-2024

    2024

  26. [34]

    Hellendoorn

    Manisha Mukherjee and Vincent J. Hellendoorn. 2024. "Medium" LMs of Code in the Era of LLMs: Lessons From StackOverflow. arXiv:2306.03268 [cs.CL] https://arxiv.org/abs/2306.03268

    2024 arXiv

  27. [35]

    2015.Why the C programming language still rules

    Daniel Munoz. 2015.Why the C programming language still rules. Retrieved July 21, 2015 from https://www.toptal. com/c/after-all-these-years-the-world-is-still-powered-by-c-programming

    2015

  28. [36]

    Yoonjong Na, Seunghoon Woo, Joomyeong Lee, and Heejo Lee. 2024. CNEPS: A Precise Approach for Examining Dependencies among Third-Party C/C++ Open-Source Components. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering(Lisbon, Portugal)(ICSE ’24)....

    2024

  29. [37]

    Olivier Nourry, Yutaro Kashiwa, Weiyi Shang, Honglin Shu, and Yasutaka Kamei. 2024. My Fuzzers Won’t Build: An Empirical Study of Fuzzing Build Failures.ACM Trans. Softw. Eng. Methodol.(aug 2024). https://doi.org/10.1145/3688842 Just Accepted

    2024 doi

  30. [38]

    npm, Inc. 2023. npm Documentation. https://docs.npmjs.com/. [Online; accessed 23-Oct-2023]

    2023

  31. [39]

    2024.Clang: A C Language Family Frontend for LLVM

    LLVM Project. 2024.Clang: A C Language Family Frontend for LLVM. LLVM Foundation. https://clang.llvm.org/ Accessed: 19-Jun-2024

    2024

  32. [40]

    Python Packaging Authority (PyPA). [n. d.]. setuptools: Easily Download, Build, Install, Upgrade, and Uninstall Python Packages. https://setuptools.pypa.io/. Accessed: 2024-09-12

    2024

  33. [41]

    Rajat Rawat, Hudson McBride, Dhiyaan Nirmal, Rajarshi Ghosh, Jong Moon, Dhruv Alamuri, Sean O’Brien, and Kevin Zhu. 2024. DiversityMedQA: Assessing Demographic Biases in Medical Diagnosis using Large Language Models. arXiv:2409.01497 [cs.CL] https://arxiv.org/abs/2409.01497

    2024 arXiv

  34. [42]

    IBM Research. 2023. LLM-based AI agents are what’s next. https://research.ibm.com/blog/what-are-ai-agents-llm Accessed: 2024-09-13

    2023

  35. [43]

    Giovanni Rosa, Antonio Mastropaolo, Simone Scalabrino, Gabriele Bavota, and Rocco Oliveto. 2023. Automatically Generating Dockerfiles via Deep Learning: Challenges and Promises. arXiv:2303.15990 [cs.SE] https://arxiv.org/abs/ 2303.15990

    2023 arXiv

  36. [44]

    Alon Talmor, Jonathan Herzig, Nicholas Lourie, and Jonathan Berant. 2019. CommonsenseQA: A Question Answering Challenge Targeting Commonsense Knowledge. arXiv:1811.00937 [cs.CL] https://arxiv.org/abs/1811.00937

    2019 arXiv

  37. [45]

    Wei Tang, Zhengzi Xu, Chengwei Liu, Jiahui Wu, Shouguo Yang, Yi Li, Ping Luo, and Yang Liu. 2022. Towards understanding third-party library dependency in c/c++ ecosystem. InProceedings of the 37th IEEE/ACM International Proc. ACM Softw. Eng., Vol. 2, No. FSE, Article FSE116. P...

    2022

  38. [46]

    Xiaojuan Tang, Zilong Zheng, Jiaqi Li, Fanxu Meng, Song-Chun Zhu, Yitao Liang, and Muhan Zhang. 2023. Large Language Models are In-Context Semantic Reasoners rather than Symbolic Reasoners. arXiv:2305.14825 [cs.CL] https://arxiv.org/abs/2305.14825

    2023 arXiv

  39. [47]

    2019.We need a safer systems programming language

    MSRC Team. 2019.We need a safer systems programming language. Retrieved July 18, 2019 from https://msrc.microsoft. com/blog/2019/07/we-need-a-safer-systems-programming-language/

    2019

  40. [48]

    The pip developers. 2024. https://pypi.org/project/pip/. Version 24.2; Accessed: 29-Jul-2024

    2024

  41. [49]

    Gladys Tyen, Hassan Mansoor, Victor Cărbune, Peter Chen, and Tony Mak. 2024. LLMs cannot find reasoning errors, but can correct them given the error location. arXiv:2311.08516 [cs.AI] https://arxiv.org/abs/2311.08516

    2024 arXiv

  42. [50]

    Eric Wallace, Kai Xiao, Reimar Leike, Lilian Weng, Johannes Heidecke, and Alex Beutel. 2024. The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions. arXiv:2404.13208 [cs.CR] https://arxiv.org/abs/2404.13208

    2024 arXiv

  43. [51]

    Xingyao Wang. 2024. OpenDevin: An Open Platform for AI Software Developers as Generalist Agents. https: //github.com/OpenDevin/OpenDevin Accessed: 2024-09-13

    2024

  44. [52]

    2024.SCons: Software Construction Tool

    Mats Wichmann. 2024.SCons: Software Construction Tool. https://scons.org/ Accessed: 12-Sep-2024

    2024

  45. [53]

    Wikipedia contributors. 2024. Software build — Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/ Software_build. [Online; accessed 11-Sep-2024]

    2024

  46. [54]

    Seunghoon Woo, Sunghan Park, Seulbae Kim, Heejo Lee, and Hakjoo Oh. 2021. CENTRIS: A Precise and Scalable Approach for Identifying Modified Open-Source Software Reuse. arXiv:2102.06182 [cs.SE] https://arxiv.org/abs/2102. 06182

    2021 arXiv

  47. [55]

    Jiahui Wu, Zhengzi Xu, Wei Tang, Lyuye Zhang, Yueming Wu, Chengyue Liu, Kairan Sun, Lida Zhao, and Yang Liu. 2023. OSSFP: Precise and Scalable C/C++ Third-Party Library Detection using Fingerprinting Functions. In2023 IEEE/ACM 45th International Conference on Software Engineer...

    2023

  48. [56]

    Yuremin. 2025. Yuremin/CXXCrafter-Community-Edition: CXXCrafter_v1.0.0-alpha (v1.0.0). https://doi.org/10.5281/ zenodo.15273210

    2025

  49. [57]

    Bo Zhang, Hui Ma, Jian Ding, Jian Wang, Bo Xu, and Hongfei Lin. 2024. Distilling Implicit Multimodal Knowledge into LLMs for Zero-Resource Dialogue Generation. arXiv:2405.10121 [cs.CL] https://arxiv.org/abs/2405.10121

    2024 arXiv

  50. [58]

    Chen Zhang, Bihuan Chen, Linlin Chen, Xin Peng, and Wenyun Zhao. 2019. A large-scale empirical study of compiler errors in continuous integration. InProceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of S...

    2019

  51. [59]

    Chen Zhang, Bihuan Chen, Junhao Hu, Xin Peng, and Wenyun Zhao. 2023. BuildSonic: Detecting and Repairing Performance-Related Configuration Smells for Continuous Integration Builds. InProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering(Ro...

    2023

  52. [60]

    Chen Zhang, Bihuan Chen, Xin Peng, and Wenyun Zhao. 2022. BuildSheriff: change-aware test failure triage for continuous integration builds. InProceedings of the 44th International Conference on Software Engineering(Pittsburgh, Pennsylvania)(ICSE ’22). Association for Computing...

    2022

  53. [61]

    Zibin Zheng, Kaiwen Ning, Yanlin Wang, Jingwen Zhang, Dewu Zheng, Mingxi Ye, and Jiachi Chen. 2024. A Survey of Large Language Models for Code: Evolution, Benchmarking, and Future Trends. arXiv:2311.10372 [cs.SE] https: //arxiv.org/abs/2311.10372

    2024 arXiv

  54. [62]

    Anni Zou, Wenhao Yu, Hongming Zhang, Kaixin Ma, Deng Cai, Zhuosheng Zhang, Hai Zhao, and Dong Yu. 2024. DOCBENCH: A Benchmark for Evaluating LLM-based Document Reading Systems. arXiv:2407.10701 [cs.CL] https://arxiv.org/abs/2407.10701 Received 2025-02-26; accepted 2025-04-01 P...

    2024 arXiv

Pith tools

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