> What you are doing is pushing all responsibility on the user. Which is exactly the ridiculous mindset that continues to make C and C++ software shit.

Correct, because that's what the C and C++ language standards say. Once the programmer writes code that hits undefined behavior, the standard says that there is no requirement on the compiler and runtime to behave in any certain way. Don't shoot the messenger; the compiler is maximizing its legal exploitation within the language standard. Blame the language standard and petition for change. (See my comment https://news.ycombinator.com/item?id=43539554 .)

> It's like having a lawless society and complaining your shit is getting stolen.

Quite the contrary; the law is written explicitly. The language standard says that something is undefined. You don't get to complain that your shit got stolen if it's undefined. It's like leaving your wallet on the street and complaining that it gets stolen, when there is absolutely no law saying that you should expect your stuff to be untouched when it's not within your private property.

> And telling people "lol, this single line of code here is invoking UB in your 100mloc codebase. Too bad that we emptied out the database, removed the backups and launched world ending nukes" is just bonkers insane.

Sadly, it's not insane. A single erroneous write can corrupt a return address or an instruction, and then the attacker can start a remote shell on your system, and nuke your machine. Not theoretical. When it comes to math, logic, and programming, any single error, no matter how small, has the potential to bring the whole house down.

Or, your program already has routines for formatting your hard drive and launching nukes, and it's protected by one flimsy if-statement. You corrupt the variable that controls that condition, and boom, everything's dead.

I hope you don't find it controversial that one arbitrary write to memory (like `(char)0x123 = 0x456;`) is sufficient grounds that nobody can predict the unbounded consequences of it. I do heavily prefer reads and overflows to be not UB though - like in Java and most other languages that came after C & C++. Again, blame the language standards, not the compiler.

> In no other human made tool is this acceptable. It's like having a hammer that accept only striking nails with between 13.732 newtons and 13.733 newtons of force if you go over or under it shoots you and your family in the face.

Hah, I take it that you're unfamiliar with mechanical engineering. For things like carbon fiber bike frames, every bolt must be tightened to a specific torque or you risk cracking the frame and possibly dying. Like, "the stem bolt must be tightened to 5 to 6 newton-metres; too loose and it'll come undone as you ride; too tight and it can damage the part". Likewise, there are examples of airplane crashes that happened because one component that should've been 1.50 mm was manufactured to like 1.40 mm, caused inappropriate rubbing with another part, caused a fuel line to burst, and you can predict the rest. At least debugging software is hell of a lot easier than debugging physical materials.

> Those two statements don't mix. You can't claim C++ has "a lot of that" backwards compatibility.

You can achieve a lot of backwards compatibility if you write code that is within the language standard and not touch UB!

Also, if you haven't done so already, read up on the notion of the C abstract machine. When the compiler analyzes you code, it doesn't think "oh you're on x86, and the add instruction doesn't trap, so your overflow is safe". No, it thinks, "the C abstract machine says that addition overflow is undefined, so we will assume that in never happens, and simplify any logic as a consequence of that assumption".