I agree with pretty much everything you wrote here. I think my main disagreement is that you can fix this at the language level. Languages are static entities; some are &quot;living&quot; in the sense that they get new major revisions (C++0x, Python 3, etc.) but on a day-to-day basis, you have to deal with the language you&#x27;ve got, and most languages don&#x27;t have any way to &quot;annotate in&quot; these sort of semantics on a per-module basis. (C is one of the only places this has been given even bare thought, actually, with compiler #pragmas.)<p>IMHO the goal of a compiler is this: to take as input 1. code represented in some standard grammar, and 2. <i>configuration</i> represented in a compiler-specific format; and to combine these two things to generate a build artifact.<p>I assume that you <i>want</i> the build artifact to have the same deterministic behavioral semantics on all target platforms, regardless of whether your language allows you to encode those semantics. Insofar as compilers have the two inputs stated above, then each semantic property that can&#x27;t be made explicit by the language grammar, <i>must then</i> fall to the compiler&#x27;s configuration.<p>In other words, it&#x27;s the compiler&#x27;s job (through you) to fix the language&#x27;s mistakes, such that vague code becomes non-vague binaries.<p>Imagine for a moment that, instead of global command-line switches passed directly to the compiler, the compiler&#x27;s configuration existed in the form of a &quot;hints file&quot; alongside each source file—effectively, a proprietary system of markup&#x2F;annotations for the language, but separated into its own file instead of being intermingled in the source like Java&#x27;s @annotations.<p>In such a model, you&#x27;d have a 1:1 correspondence between input #1 and input #2: each file of C code would have an equivalent file of hints, telling the compiler everything it needs to know that isn&#x27;t <i>in</i> the C code (and which, moreover, can&#x27;t actually be expressed at all in C.)<p>With our current backwards batch-programming methodologies, you&#x27;d probably have to write the &quot;hint&quot; files yourself, or have your IDE generate them by twiddling knobs. My real expectation, though, is that your compiler would actually run through your source files interactively, <i>asking you questions</i> where it thinks things are vague and <i>recording the answers</i> in its hint files, only actually doing a compilation pass once all its questions have been answered. Your compiler would actually work <i>with</i> you like a copy-editor, taking your muddled prose and putting in little query-marks to show its confusion.<p>Which is all to say, we&#x27;re never going to get a revision of the C language standard that will actually give &quot;x + y&quot; platform-independent overflow semantics. But we could definitely create compilers that would <i>annotate</i> each &quot;x + y&quot; in a C codebase with a particular overflow semantics, without doing anything to the code itself that breaks the C language grammar. This would let us remove the vast majority of what is currently &quot;undefined behavior&quot; from our code, without fighting a losing battle for more semantically-explicit languages.