Quotes of the week

The people who fight against “evil compiler writers” miss the point because they just don't think about how modern compilers work (actually not-so-modern, it was a problem quarter-century ago already).

The change in C99 wasn't arbitrary and, in fact, it was unavoidable. The reason is simple: phrase about “permissible undefined behavior” only makes sense for a very simple, basically trivial compiler. Which does not optimizations at all. Once you start doing optimizations you quickly find out that before you can argue if certain optimizations are valid or not and when… you need to know what “expected behavior” is. Because all optimizations, basically, depend on as if rule — but how can you apply it if you have no idea what happens in code at all? For many types of undefined behavior it's definitely not trivial… think an invalid array reference, null pointer reference. or reference to an object declared with automatic storage duration in a terminated block occurs: what kind of optimizations can you offer which would keep observable behavior the same for such a program?

Consider the following program:

#include <stdio.h>

int foo() {
  int i;
  i = 42;
}

int bar() {
  int i;
  return i;
}

int main() {
  foo();
  printf("%d\n", bar());
}

It works in GCC -O0. GCC -O2 breaks it but not in a way permitted by vyodaken's reading of C89. And Clang breaks it completely - with -O0, too yet differently with -O2.

Worse: when people start talking about examples of undefined behavior which happen in normal program they often miss the point entirely.

> Returning a pointer to indeterminate value data, surely a “use”, is not undefined behavior because the standard mandates that malloc will do that. Use of “asm” does not cause undefined behavior although it is nonportable because the standard (glancingly) mentions using asm.

See? Standard writers are idiots since noone can write a reasonable program without triggering undefined behavior! Except… returning a pointer to indeterminate value data is not use and it is allowed. It's not an undefined behavior. And asm is very explicitly permitted, it's not an “undefined behavior” either. And I'm yet to see anyone who will complain that compilers can do crazy things if something like this is violated: the format for the fprintf or fscanf function does not match the argument list.

The real problem is that when C89 was made lots of things were put in the “undefined behavior” bucket where they should have been put into “implementation-defined behavior” bucket. When C99 was made it become obvious that wording for “undefined behavior” just doesn't work - yet lots of stuff which should have been moved to “implementation-defined behavior” at this point was kept as “undefined behavior”.

But instead of trying to fix that, very real problem (and yes, when properly discussed such conversion does happen: read P0145 or P0593 for example), people attack compiler writers again and again and again.

As if that may ever change anything.

P.S. The mere fact that linux kernel or libsodium even have these switches shows that compiler writers do understand that lists of “undefined behavior”s in standard are not perfect. But demanding that compilers should stop treating “undefined behavior”s as, well… undefined and start and treating all of them as “implementation-defined” ones simply because someone doesn't have know standard well-enough… it just wouldn't fly, sorry.

I assume the main issue here is a misunderstanding of what undefined behavior actually is. Basically, you may view it as "unhandled" cases in the C semantics. The blog post seems to assume that compiler writers currently actively need to figure out a semantics for undefined behavior, and a "constructive interpretation" is to just slightly change the definition of how compiler writers should figure out the semantics. I think this is a fundamental misunderstanding. Undefined cases are basically unhandled, rather than interpreted in any way. Then, going from "unhandled" to "handled" is a fundamental change, rather than a minor change in interpretation.

The notion of undefined behavior should be interpreted in the context of section 5.1.2.3, Program execution, of the standard (excerpt):

The semantic descriptions in this document describe the behavior of an abstract machine in which issues of optimization are irrelevant.

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or through volatile access to an object).

The least requirements on a conforming implementation are:

• Volatile accesses to objects are evaluated strictly according to the rules of the abstract machine.
• At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced.
• The input and output dynamics of interactive devices shall take place as specified in 7.21.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input.

This is the observable behavior of the program.

If some C construct lack a "semantic description" – that is, is "unhandled" by the standard (but the C standard is actually currently trying to explicitly point out cases of undefined behavior) – also C language implementations (e.g. a compiler + hardware realization) can leave these C constructs "unhandled". According to my view, this is basically the origination of "undefined behavior".

Let's take a simple example (outside the domain of the C standard and compiler implementations) of a simple C function:

// Print a digit to stdout. Only 0 to 9 has defined behavior.
void print_digit(int i)

The comment documenting the function implies that values for i outside of the range 0..9 may be left unhandled by the implementation. That is, if 10 is passed as an argument, the behavior is undefined, and the function is allowed to for example crash or print "Hello world!". (But in practice the last implementation is unlikely.) This also implies that the actual behavior for out of range cases may change, when a new version of the implementation is released. The actual behavior is uninteresting from the implementors point of view and may even be unknown (requires a non-trivial amount of reverse engineering to infer).

The Linux kernel turn on some GCC options, such as -fno-strict-aliasing and -fno-strict-overflow to actually change the C semantics into something else for some C constructs. (In my opinion these options should have been listed at Options Controlling C Dialect rather than Options That Control Optimization and Options for Code Generation Conventions in the GCC documentation.) Similarly, we can also turn other cases of undefined behavior into defined behavior, by actually changing the C semantics. However, this needs to be done case-by-case, rather than trying to somehow turn all instances of undefined behavior into defined behavior, with some kind of default interpretation of undefined behavior (which I would say is impossible).

In our case with the 'print_digit' function, we may remove the undefined behavior by for example change it to:

// Print a digit to stdout. For input outside the range 0 to 9, modulo 10 arithmetic is applied.
void print_digit(int i)

But other changes are also possible. For example:

// Print a digit to stdout. For input outside the range 0 to 9, '?' is printed.
void print_digit(int i)

Both for our simple 'print_digit' function and the C standard or C compilers, the actual benefits of having something as "undefined behavior" are basically the same:

• It may simplify the implementation.
• It may make the execution more efficient.

The drawback is probably also basically the same:

• It may make the usage more risky (the program may crash or behave more unpredictably).

#include <stdio.h>
#include <stdlib.h>

int main() {
    int *p = (int*)malloc(sizeof(int));
    int *q = (int*)realloc(p, sizeof(int));
    if (p == q) {
        *p = 1;
        *q = 2;
        printf("%d %d\n", *p, *q);
    }
}

int *p = malloc(sizeof(int));
free(p);
int *q = malloc(sizeof(int));
if (p == q) {
  *p = 1;
  *q = 2;
  printf("%d %d\n", *p, *q);
}

int *p = malloc(sizeof(int));
free(p);
int *q = malloc(sizeof(int));
if (p == q) {
  *p = 1;
  *q = 2;
  printf("%d %d\n", *p, *q);
}

int *p = malloc(sizeof(int));
free(p);
int *q = malloc(sizeof(int));
if (memcmp(&p, &q, sizeof(p)) == 0) {
  *p = 1;
  *q = 2;
  printf("%d %d\n", *p, *q);
}

void * myptr = NULL;
intptr_t myintptr;
memcpy(&myintptr, &myintptr, sizeof(myptr));
printf("%ld", (long) myintptr);