I would rather have unpleasantries that make the language safer vs unpleasantries that make it more vulnerable. Especially when the unpleasantries in question don’t even make the language easier to use.
It would have taken you less time to look up -fwrapv / -ftrapv / -fsanitize=signed-integer-overflow + -fsanitize-undefined-trap-on-error than write out that misleading dialog. :)
Last time I checked ubsan was a few years ago for a small program, and I've read stuff about it not being suitable for anything outside development (more like a valgrind complement than a release option) because of how it messed with environment variables and linked libraries or something, so I might not have the full picture.
C is more likely to define wrapping arithmetic. Wrapping is defined as undefined for compatibility with MIPS processors that support checked arithmetic.
Me: "If it can't happen then it would be fine to just crash on those situations, right? Because such a crash would never be reached. Can we get that?"
C compilers: "No. Would you want to crash on signed integer overflow, for example?"
Me: "Yes? Would be safer than the current situation at least."
C compilers: "What, no, that would make your programs imperceptibly slower. Would you even like that?"
Me: "Yes, I'll be able to live with that."
C compilers: "Well, the answer is still no."