C89 C23 Three modest proposals for fixing the C standard.
C Standards



C89 C23 Three modest proposals for fixing the C standard.
Here’s a program that exhibits the low level nature of C by changing the return address of a function. The function “one” always returns the number 1 and the function “two” always returns the number 2. The main code calls
There is a nice example thread semantics in a paper by David Goldblatt (P1916R0) which illustrates a couple of things about multi-core processing – including how interesting it is and how poorly defined the C11 atomic/thread extension is . A
The C Standards process over the last few decades has addressed both optimization and pointer type safety largely through a concept called “undefined behavior”. The idea is that instead of positive rules for what compilers and programmers can do, the

Perhaps there is some reason to provide a mechanism for asserting, in a particular patch of code, that the compiler is free to make optimistic assumptions about the kinds of aliasing that can occur. I don’t know any acceptable way of
From the LLVM developer mailing list this remarkable exchange in which Chris Lattner of LLVM says that the compiler use of undefined behavior (UB) is so “crappy” that the only solution is to abandon C programming (my bold). On Jul
The Kafkaesque interaction of the C standard and the main open source C compilers was concisely outlined by one of the main LLVM authors back in 2011: “knowing that INT_MAX+1 is undefined allows optimizing X+1 > X to “true”. Knowing