pith. sign in

arxiv: 1907.00863 · v1 · pith:EM5NDTWNnew · submitted 2019-07-01 · 💻 cs.PL · cs.SE

Understanding GCC Builtins to Develop Better Tools

Manuel Rigger , Stefan Marr , Bram Adams , Hanspeter M\"ossenb\"ock This is my paper

Pith reviewed 2026-05-25 11:21 UTC · model grok-4.3

classification 💻 cs.PL cs.SE
keywords GCC builtinsC language extensionscompiler compatibilityGitHub corpus analysistool supportbuiltin evolution
0
0 comments X

The pith

Implementing 10 GCC builtins covers over 30 percent of C projects that use them.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper examines builtin usage across 4,913 C projects hosted on GitHub. It reports that 37 percent of projects call at least one GCC builtin, yet usage concentrates sharply so that a small set of builtins accounts for the majority of projects. The authors track how builtin calls evolve in each project and observe that most projects add rather than remove them. They also test a range of existing tools and find that many provide only partial support or contain incorrect implementations.

Core claim

A corpus study of 4,913 C projects shows that builtin calls are common yet concentrated, with 10 builtins already covering more than 30 percent of projects and roughly 110 builtins sufficient to reach 90 percent coverage; the same study finds that projects continue to introduce new builtin uses over time and that many mature tools, including CompCert, lack complete or correct support for the builtins actually used.

What carries the argument

Static detection of builtin calls across a large GitHub corpus, followed by coverage calculations and per-project evolution tracking.

If this is right

  • Tool authors can achieve broad compatibility by focusing implementation effort on the most frequent builtins first.
  • Because projects keep adding builtins, future tools cannot treat them as a legacy feature to be ignored.
  • Existing compiler and analysis tools need targeted fixes for the builtins that projects actually invoke.
  • Formally verified compilers must expand their builtin models if they are to handle the same code bases as mainstream compilers.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The concentration of usage suggests that a modest, curated builtin library could serve as a practical compatibility layer for many new analysis and transformation tools.
  • Projects that rely on builtins may become harder to port to environments without GCC or Clang, increasing the value of tools that emulate those builtins.
  • The finding that even verified compilers contain incorrect builtin implementations points to a need for systematic test suites derived from real project usage.

Load-bearing premise

The 4,913 GitHub projects form a representative sample of C code that uses builtins and the static analysis used to detect builtin calls has low false-positive and false-negative rates.

What would settle it

A new corpus of C projects drawn from a different source that requires a substantially larger number of builtins to reach 90 percent coverage, or a tool that implements the top 110 builtins yet still fails to build 90 percent of the original projects.

Figures

Figures reproduced from arXiv: 1907.00863 by Bram Adams, Hanspeter M\"ossenb\"ock, Manuel Rigger, Stefan Marr.

Figure 1
Figure 1. Figure 1: Number of architecture-specific and architecture [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The number of projects that rely on architecture-independent and architecture-specific builtins. [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: The numbers of builtins needed to support an in [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Builtin development in tinycbor, hashcat, libav, and libucl. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: The test-case results before bugs were fixed or [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
read the original abstract

C programs can use compiler builtins to provide functionality that the C language lacks. On Linux, GCC provides several thousands of builtins that are also supported by other mature compilers, such as Clang and ICC. Maintainers of other tools lack guidance on whether and which builtins should be implemented to support popular projects. To assist tool developers who want to support GCC builtins, we analyzed builtin use in 4,913 C projects from GitHub. We found that 37% of these projects relied on at least one builtin. Supporting an increasing proportion of projects requires support of an exponentially increasing number of builtins; however, implementing only 10 builtins already covers over 30% of the projects. Since we found that many builtins in our corpus remained unused, the effort needed to support 90% of the projects is moderate, requiring about 110 builtins to be implemented. For each project, we analyzed the evolution of builtin use over time and found that the majority of projects mostly added builtins. This suggests that builtins are not a legacy feature and must be supported in future tools. Systematic testing of builtin support in existing tools revealed that many lacked support for builtins either partially or completely; we also discovered incorrect implementations in various tools, including the formally verified CompCert compiler.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper analyzes GCC builtin usage across 4,913 C projects from GitHub, reporting that 37% use at least one builtin. It finds that 10 builtins cover >30% of projects while ~110 suffice for 90%, that builtin use is actively increasing rather than legacy, and that many tools (including CompCert) have incomplete or incorrect builtin support.

Significance. If the corpus and detection are representative and accurate, the work supplies actionable prioritization data for tool maintainers and documents real gaps in production and verified compilers. The longitudinal finding that projects mostly add builtins strengthens the case for ongoing support.

major comments (3)
  1. [§3] §3 (Corpus construction): The selection criteria for the 4,913 GitHub projects are not stated (minimum stars, repository size, C standard, fork handling, or platform). Without these, the headline coverage figures (10 builtins for >30%, 110 for 90%) cannot be assessed for generalizability.
  2. [§3.2] §3.2 (Builtin detection): The static-analysis procedure used to identify builtin calls is described only at high level; no information is given on whether detection is string-based, AST-based, handles macros, or was validated on a manually labeled sample. This directly affects the reliability of all reported percentages and the exponential-coverage claim.
  3. [§5] §5 (Tool evaluation): The specific builtins found to be incorrectly implemented in CompCert and other tools are not enumerated, nor are the test cases or failure modes. This makes the claim of “incorrect implementations” hard to verify or act upon.
minor comments (2)
  1. The coverage curve (presumably Figure 2 or 3) would be clearer with a table of the top-20 builtins and their cumulative project coverage.
  2. The abstract states headline numbers without referencing the sections that contain the supporting methodology; cross-references would improve readability.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive comments, which highlight areas where additional methodological detail will improve the paper. We address each major comment below and will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: [§3] §3 (Corpus construction): The selection criteria for the 4,913 GitHub projects are not stated (minimum stars, repository size, C standard, fork handling, or platform). Without these, the headline coverage figures (10 builtins for >30%, 110 for 90%) cannot be assessed for generalizability.

    Authors: We agree that explicit selection criteria are necessary for assessing generalizability. In the revised version we will add a dedicated subsection detailing the project selection process, including any thresholds on repository popularity, size, language constraints, fork handling, and platform considerations used to arrive at the final corpus of 4,913 projects. revision: yes

  2. Referee: [§3.2] §3.2 (Builtin detection): The static-analysis procedure used to identify builtin calls is described only at high level; no information is given on whether detection is string-based, AST-based, handles macros, or was validated on a manually labeled sample. This directly affects the reliability of all reported percentages and the exponential-coverage claim.

    Authors: We acknowledge that the current description of the detection procedure is insufficiently detailed. We will expand §3.2 to specify the exact analysis technique (including whether it operates on source text, the AST, or preprocessor output), how macro expansions are handled, and any validation steps performed against manually inspected samples. revision: yes

  3. Referee: [§5] §5 (Tool evaluation): The specific builtins found to be incorrectly implemented in CompCert and other tools are not enumerated, nor are the test cases or failure modes. This makes the claim of “incorrect implementations” hard to verify or act upon.

    Authors: We agree that enumerating the concrete cases would make the evaluation more actionable. In the revision we will list the specific builtins exhibiting incorrect behavior in each evaluated tool, together with the test cases used and the observed failure modes. revision: yes

Circularity Check

0 steps flagged

No circularity; results are direct empirical counts from external corpus

full rationale

The paper performs a static analysis of builtin usage across 4,913 GitHub C projects and reports coverage statistics (e.g., 10 builtins covering >30% of projects, ~110 for 90%) as direct aggregates of observed call sites. No equations, fitted parameters, predictions, or self-citations appear in the derivation; the reported percentages are computed outputs from the collected data rather than inputs redefined as results. The analysis is self-contained against the external project corpus and tool executions described.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The paper is a pure empirical measurement study. It introduces no fitted parameters, no new mathematical axioms beyond standard statistical sampling assumptions, and no invented entities.

axioms (1)
  • domain assumption The 4,913 GitHub C projects constitute a representative sample for generalizing builtin-usage statistics to the broader population of C code.
    The headline coverage percentages rest on this sampling assumption stated in the abstract's methodology summary.

pith-pipeline@v0.9.0 · 5753 in / 1268 out tokens · 25271 ms · 2026-05-25T11:21:02.496377+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

69 extracted references · 69 canonical work pages · 1 internal anchor

  1. [1]

    Roy, and Kevin A

    Muhammad Asaduzzaman, Muhammad Ahasanuzzaman, Chanchal K. Roy, and Kevin A. Schneider. 2016. How Developers Use Exception Handling in Java?. In Proceedings of the 13th International Conference on Mining Software Repositories (MSR ’16). ACM, New York, NY, USA, 516–519. https://doi.org/10.1145/2901739. 2903500

    work page doi:10.1145/2901739 2016

  2. [2]

    Hora, and Marco Tulio Valente

    Hudson Borges, André C. Hora, and Marco Tulio Valente. 2016. Understanding the Factors That Impact the Popularity of GitHub Repositories. In 2016 IEEE International Conference on Software Maintenance and Evolution, ICSME 2016, Raleigh, NC, USA, October 2-7, 2016 . 334–344. https://doi.org/10.1109/ICSME. 2016.31

    work page doi:10.1109/icsme 2016

  3. [3]

    Cristian Cadar, Daniel Dunbar, and Dawson Engler. 2008. KLEE: unassisted and automatic generation of high-coverage tests for complex systems programs. In Proceedings of the 8th USENIX conference on Operating systems design and implementation (OSDI’08). USENIX Association, Berkeley, CA, USA, 209–224

    work page 2008

  4. [4]

    Campbell, Charles Quincy, Jordan Osserman, and Ove K

    John L. Campbell, Charles Quincy, Jordan Osserman, and Ove K. Pedersen. 2013. Coding In-depth Semistructured Interviews: Problems of Unitization and Inter- coder Reliability and Agreement. Sociological Methods & Research 42, 3 (2013), 294–320

    work page 2013

  5. [5]

    Casey Casalnuovo, Prem Devanbu, Abilio Oliveira, Vladimir Filkov, and Baishakhi Ray. 2015. Assert Use in GitHub Projects. In Proceedings of the 37th International Conference on Software Engineering - Volume 1 (ICSE ’15) . IEEE Press, Piscataway, NJ, USA, 755–766

    work page 2015

  6. [6]

    Clang Team. 2018. Clang Language Extensions. Builtin Functions. https: //clang.llvm.org/docs/LanguageExtensions.html

    work page 2018

  7. [7]

    Ward Cunningham. 1993. The WyCash portfolio management system. 4 (04 1993), 29–30

    work page 1993

  8. [8]

    Pascal Cuoq, Florent Kirchner, Nikolai Kosmatov, Virgile Prevosto, Julien Signoles, and Boris Yakobowski. 2012. Frama-C. In Software Engineering and Formal Methods, George Eleftherakis, Mike Hinchey, and Mike Holcombe (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 233–247

    work page 2012

  9. [9]

    Will Dietz, Peng Li, John Regehr, and Vikram Adve. 2012. Understanding Integer Overflow in C/C++. (2012), 760–770

    work page 2012

  10. [10]

    DiStaso and Denise Sevick Bortree

    Marcia W. DiStaso and Denise Sevick Bortree. 2012. Multi-method analysis of transparency in social media practices: Survey, interviews and content analysis. Public Relations Review 38, 3 (2012), 511–514. https://doi.org/10.1016/j.pubrev. 2012.01.003 Public Relations History

    work page doi:10.1016/j.pubrev 2012

  11. [11]

    Robert Dyer, Hridesh Rajan, Hoan Anh Nguyen, and Tien N. Nguyen. 2014. Mining Billions of AST Nodes to Study Actual and Potential Usage of Java Language Features. In 36th International Conference on Software Engineering (ICSE’14). 779–790

    work page 2014

  12. [12]

    Chucky Ellison and Grigore Rosu. 2012. An Executable Formal Semantics of C with Applications. In Proceedings of the 39th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL ’12) . ACM, New York, NY, USA, 533–544. https://doi.org/10.1145/2103656.2103719

    work page doi:10.1145/2103656.2103719 2012

  13. [13]

    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. https://doi.org/10.1109/TSE.2002.1158288

    work page doi:10.1109/tse.2002.1158288 2002

  14. [14]

    David Evans, John Guttag, James Horning, and Yang Meng Tan. 1994. LCLint: A Tool for Using Specifications to Check Code. (1994), 87–96. https://doi.org/10. 1145/193173.195297

    work page arXiv 1994

  15. [15]

    David Evans and David Larochelle. 2002. Improving Security Using Extensible Lightweight Static Analysis. IEEE Softw. 19, 1 (Jan. 2002), 42–51. https://doi.org/ 10.1109/52.976940

    work page doi:10.1109/52.976940 2002

  16. [16]

    Chris Hathhorn, Chucky Ellison, and Grigore Roşu. 2015. Defining the Undefined- ness of C. In Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ’15) . ACM, New York, NY, USA, 336–345. https://doi.org/10.1145/2737924.2737979

    work page doi:10.1145/2737924.2737979 2015

  17. [17]

    Gerard J Holzmann. 2002. UNO: Static source code checking for user-defined properties. In Proc. IDPT, Vol. 2

    work page 2002

  18. [18]

    Intel. [n.d.]. Cilk Plus. https://www.cilkplus.org/

    work page

  19. [19]

    German, and Daniela Damian

    Eirini Kalliamvakou, Georgios Gousios, Kelly Blincoe, Leif Singer, Daniel M. German, and Daniela Damian. 2014. The Promises and Perils of Mining GitHub. In Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014). ACM, New York, NY, USA, 92–101. https://doi.org/10.1145/2597073. 2597074

    work page doi:10.1145/2597073 2014

  20. [20]

    Mulligan, and Peter Sewell

    Stephen Kell, Dominic P. Mulligan, and Peter Sewell. 2016. The Missing Link: Explaining ELF Static Linking, Semantically. In Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2016) . ACM, New York, NY, USA, 607–623. https://doi.org/10.1145/2983990.2983996

    work page doi:10.1145/2983990.2983996 2016

  21. [21]

    Florent Kirchner, Nikolai Kosmatov, Virgile Prevosto, Julien Signoles, and Boris Yakobowski. 2015. Frama-C: A software analysis perspective. Formal Aspects of Computing 27, 3 (May 2015), 573–609. https://doi.org/10.1007/s00165-014-0326-7

    work page doi:10.1007/s00165-014-0326-7 2015

  22. [22]

    Julia Koval. 2017. remove cilk-plus. https://gcc.gnu.org/ml/gcc-patches/2017- 11/msg01345.html

    work page 2017

  23. [23]

    Robbert Krebbers and Freek Wiedijk. 2015. A Typed C11 Semantics for Interactive Theorem Proving. In Proceedings of the 2015 Conference on Certified Programs and Proofs (CPP ’15). ACM, New York, NY, USA, 15–27. https://doi.org/10.1145/ 2676724.2693571

    work page arXiv 2015

  24. [24]

    Chris Lattner and Vikram Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In Proceedings of the International Symposium on Code Generation and Optimization: Feedback-directed and Runtime Optimization (CGO ’04). IEEE Computer Society, Washington, DC, USA, 75–

    work page 2004

  25. [25]

    Xavier Leroy. 2009. Formal Verification of a Realistic Compiler. Commun. ACM 52, 7 (July 2009), 107–115. https://doi.org/10.1145/1538788.1538814

    work page doi:10.1145/1538788.1538814 2009

  26. [26]

    Xavier Leroy. 2009. A formally verified compiler back-end. Journal of Automated Reasoning 43, 4 (2009), 363–446

    work page 2009

  27. [27]

    Matthew Lombard, Jennifer Snyder-Duch, and Cheryl Campanella Bracken. [n.d.]. Content Analysis in Mass Communication: Assessment and Reporting of In- tercoder Reliability. Human Communication Research 28, 4 ([n. d.]), 587–604. https://doi.org/10.1111/j.1468-2958.2002.tb00826.x

    work page doi:10.1111/j.1468-2958.2002.tb00826.x 2002

  28. [28]

    Lopes, Petr Maj, Pedro Martins, Vaibhav Saini, Di Yang, Jakub Zitny, Hitesh Sajnani, and Jan Vitek

    Cristina V. Lopes, Petr Maj, Pedro Martins, Vaibhav Saini, Di Yang, Jakub Zitny, Hitesh Sajnani, and Jan Vitek. 2017. DéJàVu: A Map of Code Duplicates on GitHub. Proc. ACM Program. Lang. 1, OOPSLA (Oct. 2017), 84:1–84:28. https: //doi.org/10.1145/3133908

    work page doi:10.1145/3133908 2017

  29. [29]

    Martin, James R

    Douglas H. Martin, James R. Cordy, Bram Adams, and Giulio Antoniol. 2015. Make It Simple: An Empirical Analysis of GNU Make Feature Use in Open Source Projects. In Proceedings of the 2015 IEEE 23rd International Conference on Program Comprehension (ICPC ’15). IEEE Press, Piscataway, NJ, USA, 207–217

    work page 2015

  30. [30]

    Davood Mazinanian, Ameya Ketkar, Nikolaos Tsantalis, and Danny Dig. 2017. Understanding the Use of Lambda Expressions in Java. Proc. ACM Program. Lang. 1, OOPSLA (Oct. 2017), 85:1–85:31. https://doi.org/10.1145/3133909

    work page doi:10.1145/3133909 2017

  31. [31]

    Kayvan Memarian, Justus Matthiesen, James Lingard, Kyndylan Nienhuis, David Chisnall, Robert N. M. Watson, and Peter Sewell. 2016. Into the Depths of C: Elaborating the De Facto Standards. In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ’16) . ACM, New York, NY, USA, 1–15. https://doi.org/10.1145/2...

    work page doi:10.1145/2908080.2908081 2016

  32. [32]

    Samim Mirhosseini and Chris Parnin. 2017. Can Automated Pull Requests En- courage Software Developers to Upgrade Out-of-date Dependencies?. In Pro- ceedings of the 32Nd IEEE/ACM International Conference on Automated Soft- ware Engineering (ASE 2017) . IEEE Press, Piscataway, NJ, USA, 84–94. http: //dl.acm.org/citation.cfm?id=3155562.3155577

    work page arXiv 2017

  33. [33]

    Nuthan Munaiah, Steven Kroh, Craig Cabrey, and Meiyappan Nagappan. 2017. Curating GitHub for Engineered Software Projects. Empirical Softw. Engg. 22, 6 (Dec. 2017), 3219–3253. https://doi.org/10.1007/s10664-017-9512-6

    work page doi:10.1007/s10664-017-9512-6 2017

  34. [34]

    Meiyappan Nagappan, Romain Robbes, Yasutaka Kamei, Éric Tanter, Shane McIn- tosh, Audris Mockus, and Ahmed E. Hassan. 2015. An Empirical Study of Goto in C Code from GitHub Repositories. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015) . ACM, New York, NY, USA, 404–414. https://doi.org/10.1145/2786805.2786834

    work page doi:10.1145/2786805.2786834 2015

  35. [35]

    Meiyappan Nagappan, Thomas Zimmermann, and Christian Bird. 2013. Diversity in Software Engineering Research. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2013) . ACM, New York, NY, USA, 466–476. https://doi.org/10.1145/2491411.2491415

    work page doi:10.1145/2491411.2491415 2013

  36. [37]

    In Proceedings of the 30th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ’09)

    SoftBound: Highly Compatible and Complete Spatial Memory Safety for C. In Proceedings of the 30th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ’09) . ACM, New York, NY, USA, 245–258. https://doi.org/10.1145/1542476.1542504

    work page doi:10.1145/1542476.1542504

  37. [38]

    Martin, and Steve Zdancewic

    Santosh Nagarakatte, Jianzhou Zhao, Milo M.K. Martin, and Steve Zdancewic

    work page

  38. [39]

    Proceedings of the International Symposium on Memory Management 45, 8 (June 2010), 31–40

    CETS: Compiler Enforced Temporal Safety for C. Proceedings of the International Symposium on Memory Management 45, 8 (June 2010), 31–40

    work page 2010

  39. [40]

    Suman Nakshatri, Maithri Hegde, and Sahithi Thandra. 2016. Analysis of Excep- tion Handling Patterns in Java Projects: An Empirical Study. InProceedings of the 13th International Conference on Mining Software Repositories (MSR ’16) . ACM, New York, NY, USA, 500–503. https://doi.org/10.1145/2901739.2903499

    work page doi:10.1145/2901739.2903499 2016

  40. [41]

    Necula, Scott McPeak, Shree Prakash Rahul, and Westley Weimer

    George C. Necula, Scott McPeak, Shree Prakash Rahul, and Westley Weimer

    work page

  41. [42]

    In Proceedings of the 11th International Conference on Compiler Construction (CC ’02)

    CIL: Intermediate Language and Tools for Analysis and Transformation of C Programs. In Proceedings of the 11th International Conference on Compiler Construction (CC ’02). Springer-Verlag, London, UK, UK, 213–228

    work page

  42. [43]

    Semih Okur, Danny Dig, and Yu Lin. 2015. Study and Refactoring of Android Asynchronous Programming. (2015)

    work page 2015

  43. [44]

    Oleksii Oleksenko, Dmitrii Kuvaiskii, Pramod Bhatotia, Pascal Felber, and Christof Fetzer. 2017. Intel MPX Explained: An Empirical Study of Intel MPX and Software- based Bounds Checking Approaches. CoRR abs/1702.00719 (2017). ESEC/FSE ’19, August 26–30, 2019, Tallinn, Estonia Manuel Rigger, Stefan Marr, Bram Adams, and Hanspeter Mössenböck

    work page internal anchor Pith review Pith/arXiv arXiv 2017

  44. [45]

    John O’Neill. 2006. Intel Compilers for Linux: Compatibility with GNU Compil- ers

    work page 2006

  45. [46]

    Thomas Pointhuber. 2017. Add some testcases for builtins, little bugfixes (Sulong GitHub Pull Request). https://github.com/graalvm/sulong/pull/807

    work page 2017

  46. [47]

    Barr, and Zhendong Su

    Dong Qiu, Bixin Li, Earl T. Barr, and Zhendong Su. 2017. Understanding the syntactic rule usage in java. Journal of Systems and Software 123 (2017), 160–172. https://doi.org/10.1016/j.jss.2016.10.017

    work page doi:10.1016/j.jss.2016.10.017 2017

  47. [48]

    Dan Quinlan. 2000. ROSE: Compiler Support for Object-Oriented Frameworks. In Proceedings of Conference on Parallel Compilers (CPC2000), Aussois, France (Parallel Processing Letters), Vol. 10. Springer Verlag

    work page 2000

  48. [49]

    Manuel Rigger. 2018. GCC Builtin Support (CIL Github Bug Report). https: //github.com/cil-project/cil/issues/44

    work page 2018

  49. [50]

    Manuel Rigger. 2018. GCC Builtins (C-Semantics GitHub Bug Report). https: //github.com/kframework/c-semantics/issues/318

    work page 2018

  50. [51]

    Manuel Rigger. 2018. GCC Builtins Support (Frama-C Mailing List). https: //lists.gforge.inria.fr/pipermail/frama-c-discuss/2018-July/005483.html

    work page 2018

  51. [52]

    Manuel Rigger. 2018. Support of GCC Builtins (CompCert GitHub Bug Report). https://github.com/AbsInt/CompCert/issues/243

    work page 2018

  52. [53]

    Manuel Rigger. 2018. Support of GCC Builtins (Tiny C Compiler Mailing List). http://lists.nongnu.org/archive/html/tinycc-devel/2018-07/msg00007.html

    work page 2018

  53. [54]

    Manuel Rigger. 2018. Unused GCC builtins (GCC Mailing List). https://gcc.gnu. org/ml/gcc/2018-01/msg00166.html

    work page 2018

  54. [55]

    Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck. 2016. Bringing Low-level Languages to the JVM: Efficient Execution of LLVM IR on Truffle. InProceedings of the 8th International Workshop on Virtual Machines and Intermediate Languages (VMIL 2016) . ACM, New York, NY, USA, 6–15. https://doi.org/10.1145/2998415.2998416

    work page doi:10.1145/2998415.2998416 2016

  55. [56]

    Manuel Rigger, Stefan Marr, Stephen Kell, David Leopoldseder, and Hanspeter Mössenböck. 2018. An Analysis of x86-64 Inline Assembly in C Programs. In Proceedings of the 14th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE ’18) . ACM, New York, NY, USA, 84–99. https: //doi.org/10.1145/3186411.3186418

    work page doi:10.1145/3186411.3186418 2018

  56. [57]

    Manuel Rigger, Daniel Pekarek, and Hanspeter Mössenböck. 2018. Context- Aware Failure-Oblivious Computing as a Means of Preventing Buffer Overflows. (2018), 376–390. https://doi.org/10.1007/978-3-030-02744-5_28

    work page doi:10.1007/978-3-030-02744-5_28 2018

  57. [58]

    Manuel Rigger, Roland Schatz, Rene Mayrhofer, Matthias Grimmer, and Hanspeter Mössenböck. 2018. Introspection for C and its Applications to Li- brary Robustness. The Art, Science, and Engineering of Programming 2 (2018). https://doi.org/10.22152/programming-journal.org/2018/2/4

    work page doi:10.22152/programming-journal.org/2018/2/4 2018

  58. [59]

    Manuel Rigger, Roland Schatz, René Mayrhofer, Matthias Grimmer, and Hanspeter Mössenböck. 2018. Sulong, and Thanks for All the Bugs: Finding Errors in C Programs by Abstracting from the Native Execution Model. In Pro- ceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’18)...

    work page doi:10.1145/3173162.3173174 2018

  59. [60]

    Demóstenes Sena, Roberta Coelho, Uirá Kulesza, and Rodrigo Bonifácio. 2016. Understanding the Exception Handling Strategies of Java Libraries: An Empirical Study. In Proceedings of the 13th International Conference on Mining Software Repositories (MSR ’16). ACM, New York, NY, USA, 212–222. https://doi.org/10. 1145/2901739.2901757

    work page arXiv 2016

  60. [61]

    Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. 2012. AddressSanitizer: A Fast Address Sanity Checker.. In USENIX Annual Technical Conference. 309–318

    work page 2012

  61. [62]

    Evgeniy Stepanov and Konstantin Serebryany. 2015. MemorySanitizer: fast detector of uninitialized memory use in C++. InCode Generation and Optimization (CGO), 2015 IEEE/ACM International Symposium on . IEEE, 46–55

    work page 2015

  62. [63]

    Sutton, Ryan Holeman, and Jonathan I

    Andrew M. Sutton, Ryan Holeman, and Jonathan I. Maletic. 2010. Identification of Idiom Usage in C++ Generic Libraries. In The 18th IEEE International Conference on Program Comprehension, ICPC 2010, Braga, Minho, Portugal, June 30-July 2,

    work page 2010

  63. [64]

    https://doi.org/10.1109/ICPC.2010.37

    160–169. https://doi.org/10.1109/ICPC.2010.37

    work page doi:10.1109/icpc.2010.37 2010

  64. [65]

    Ewan Tempero, James Noble, and Hayden Melton. 2008. How Do Java Programs Use Inheritance? An Empirical Study of Inheritance in Java Software. In Proceed- ings of the 22Nd European Conference on Object-Oriented Programming (ECOOP ’08). Springer-Verlag, Berlin, Heidelberg, 667–691. https://doi.org/10.1007/978-3- 540-70592-5_28

    work page doi:10.1007/978-3- 2008

  65. [66]

    Ewan D. Tempero. 2009. How Fields are Used in Java: An Empirical Study. In 20th Australian Software Engineering Conference (ASWEC 2009), 14-17 April 2009, Gold Cost, Australia. 91–100. https://doi.org/10.1109/ASWEC.2009.19

    work page doi:10.1109/aswec.2009.19 2009

  66. [67]

    Di Wu, Lin Chen, Yuming Zhou, and Baowen Xu. 2014. An empirical study on the adoption of C++ templates: Library templates versus user defined templates. In The 26th International Conference on Software Engineering and Knowledge Engineering, Hyatt Regency, Vancouver, BC, Canada, July 1-3, 2013. 144–149

    work page 2014

  67. [68]

    Di Wu, Lin Chen, Yuming Zhou, and Baowen Xu. 2016. An extensive empirical study on C++ concurrency constructs. Information & Software Technology 76 (2016), 1–18. https://doi.org/10.1016/j.infsof.2016.04.004

    work page doi:10.1016/j.infsof.2016.04.004 2016

  68. [69]

    Deng Xu. 2011. [Frama-c-discuss] inline assembly code. https://lists.gforge.inria. fr/pipermail/frama-c-discuss/2011-March/002589.html (Accessed October 2017)

    work page 2011

  69. [70]

    Zhongxing Xu, Ted Kremenek, and Jian Zhang. 2010. A Memory Model for Static Analysis of C Programs. In Proceedings of the 4th International Conference on Leveraging Applications of Formal Methods, Verification, and Validation - Volume Part I (ISoLA’10). Springer-Verlag, Berlin, Heidelberg, 535–548

    work page 2010