Into the depths of C: elaborating the de facto standards

Abstract

C remains central to our computing infrastructure. It is notionally defined by ISO standards, but in reality the properties of C assumed by systems code and those implemented by compilers have diverged, both from the ISO standards and from each other, and none of these are clearly understood.We make two contributions to help improve this errorprone situation. First, we describe an in-depth analysis of the design space for the semantics of pointers and memory in C as it is used in practice. We articulate many specific questions, build a suite of semantic test cases, gather experimental data from multiple implementations, and survey what C experts believe about the de facto standards. We identify questions where there is a consensus (either following ISO or differing) and where there are conflicts. We apply all this to an experimental C implemented above capability hardware. Second, we describe a formal model, Cerberus, for large parts of C. Cerberus is parameterised on its memory model; it is linkable either with a candidate de facto memory object model, under construction, or with an operational C11 concurrency model; it is defined by elaboration to a much simpler Core language for accessibility, and it is executable as a test oracle on small examples. This should provide a solid basis for discussion of what mainstream C is now: what programmers and analysis tools can assume and what compilers aim to implement. Ultimately we hope it will be a step towards clear, consistent, and accepted semantics for the various use-cases of C.

EffectiveSan: type and memory error detection using dynamically typed C/C++

“…For example, there is no tracking of pointer provenance [12]. Furthermore, the prototype implements some common "sloppy" [20] and "de facto" [26] extensions, such as (T *) to/from (void *) coercions. The final limitation relates to sub-object matching.…”

“…Structure types with flexible array members; and 2. Automatic coercions between types allowable under the C, "sloppy" [20] or "de facto" [26] standards. .…”

SoK: Sanitizing for Security

“…The most frequently recurring problem is that sanitizers often implement a bug finding policy or mechanism which is stricter than either the language standard or the de facto standard. The de facto standard includes widely-followed programming practices that do not necessarily comply with the language standard, even though they result in bug-free code [94]. One could therefore argue that reporting behavior that does not comply with the de facto standard as a bug constitutes a false positive detection.…”

Understanding GCC builtins to develop better tools

“…Our results are expected to help tool developers in prioritizing implementation effort, maintenance, and optimization of builtins. Thus, this study facilitates the development of compilers such as GCC, Clang [24], ICC, and the formally verified CompCert compiler [25,26]; of static-analysis tools such as the Clang Static Analyzer [66], splint [14,15], Frama-C [65], and uno [17]; of semantic models for C [23,31]; and of alternative execution environments and bug-finding tools such as KLEE [3], Sulong [52,56], the LLVM sanitizers [58,59], and SoftBound [36,37]. For reproducibility and verifiability, we provide the database with GCC builtin usage, test suite, tools used for the analysis, and a record of the manual decisions on https:// github.com/ jku-ssw/ gcc-builtin-study.…”