And therein lies a major problem with c and c++ compilers:

It's effectively impossible to write bug free code. Bugs in c and c++ usually trigger undefined behavior. It is therefore impossible to write a conforming program, which makes any guarantees in the spec meaningless.

I've hit heisenbugs like these that only trigger when optimized, and resist write(), out(), fflush(), etc and it's infuriating.

Or even worse: programs that no longer work when compiled on a newer compiler. With other languages, you are at least spared from this kind of code decay.

But everyone's writing compilers to the spec so tough :/

"Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific. C++ has a standard, unlike languages like Rust or Python. This is a good thing, because compiler-specific crap doesn't magically go away if you avoid standards and just declare one implementation as a "reference".

> "Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific.

Yes, it does. The behavior you are describing is "implementation specific", and it is ok to have this in your program provided you know what your implementation will do. It is illegal to have any undefined behavior in a well-formed C/C++ program.

The standard doesn't defined well-formedness, nor does it consider undefined behaviour illegal necessarily. It simply has nothing to say about what happens when undefined behaviour is invoked.

And it is OK to invoke it if you know what your implementation will do. The standard even gives documenting the behaviour as an option.

(I wonder how many people worry about supplying clang a file that doesn't end in a new line? That is undefined behaviour, and yet you know exactly what's going to happen: you'll get a warning, if compilation continues the code will build as if the new line were there, and clang won't delete your source file, even though it would be perfectly within its rights to.)

It no longer is, since C++11. Check Phase 2.2 here: https://en.cppreference.com/w/cpp/language/translation_phase...

> clang won't delete your source file, even though it would be perfectly within its rights to.

UB allows the execution of the compiled program to wipe your hard drive, but it certainly does not give your compiler that right. I mean, the standard doesn't say what side effects invoking a compiler is allowed to have (because that's out of scope), so none of it can be predicated on UB.

(Mandatory mention: https://github.com/munificent/vigil)