A Guide to Undefined Behavior in C and C++

If you want some nice examples of how undefined behavior results in weirdness, see https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63... An interesting example from there is how the compiler can turn int table[4]; bool exists_in_table(int v) { for (int i = 0; i <= 4; i++) { if (table[i] == v) return true; } return false; } Into: bool exists_in_table(int v) { return true; }

This is an area the newer languages get right - I don’t think Rust or Go has any undefined behavior? I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly.

For those viewing this thread, one year after this article was written, this was standardized: https://en.cppreference.com/w/cpp/numeric/fenv

> undefined behavior in C/C++ is that it simplifies the compiler’s job, making it possible to generate very efficient code in certain situations. I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap? Second, it seems counter productive. The word is now out that if you use signed ints, the compiler…