That's C, baby. C!

TL;DR

This paper argues that the meaning of C code cannot be fully determined without complete knowledge of the build environment and toolchain, due to the language's complex and undefined semantics.

Contribution

It highlights the importance of build context for understanding C code and clarifies misconceptions about C source code having intrinsic meaning.

Findings

C semantics are not fully defined, leading to ambiguity.

Full build details are necessary to interpret C code meaning.

Most C code's meaning depends on external build environment.

Abstract

Hardly a week goes by at BUGSENG without having to explain to someone that almost any piece of C text, considered in isolation, means absolutely nothing. The belief that C text has meaning in itself is so common, also among seasoned C practitioners, that I thought writing a short paper on the subject was a good time investment. The problem is due to the fact that the semantics of the C programming language is not fully defined: non-definite behavior, predefined macros, different library implementations, peculiarities of the translation process, . . . : all these contribute to the fact that no meaning can be assigned to source code unless full details about the build are available. The paper starts with an exercise that admits a solution. The existence of this solution will hopefully convince anyone that, in general, unless the toolchain and the build procedure are fully known, no meaning can be assigned to any nontrivial piece of C code.