What is the point of undefined behavior? [duplicate]

Question

I can understand leaving something implementation defined, so that the particular people implementing it would know what's best to happen, but why would something ever be undefined behavior? Why not just say, anything else is implementation defined?

Answer 1

There are a lot of cases in which ensuring an implementation defined behavior inevitably incurs overhead.

For example, how to make buffer overflow an implementation defined behavior? Maybe throw exception when it's detected, or maybe terminate the program? But doing that always requires bounds-checking.

C++ is designed in such a way that performance is almost never compromised.

There are languages like Go, Rust, and Java which do bounds-checking. And they all incur overhead to pay the price for the safety.

Answer 2

Language specifications can be seen as a contract between the compiler writers and programmers. There are things that programmers assume that compiler would do (and not do). Compiler writers assume few things a programmer would do.

Compiler writer assumes programmer would write the code that has documented behavior or is free from undefined behavior. Based on that compiler writers can ignore some constructs and can make the compiled program faster as compared to the case if those constructs were not undefined. Some of such (as much as possible) undefined constructs are documented in the specifications to give the programmers an idea of such constructs.

Such undefined behavior exist to reduce the unnecessary complexity in implementation of specifications and sometimes to leave rooms for optimization.