> definition is so vague as to be totally useless from a programming perspective. Avoid invoking UB, or all hell breaks loose. How useful it is from a programm

> definition is so vague as to be totally useless from a programming perspective. Avoid invoking UB, or all hell breaks loose. How useful it is from a programming perspective is moot because this is the only possible definition if you want a) A language that is powerful enough it can violate the invariants the compiler establishes and upholds in the runtime environment and then (necessarily) assumes are being upheld, and b) any meaningful optimizations at all. What's not reasonable in C is the extent to which stuff lazily gets shoved under the UB umbrella, but the concept itself is not avoidable if you give the programmer enough leeway to conjure up arbitrary pointers out of thin air (but even much less would necessitate UB). What's vague to the extent of being totally useless from a specification perspective is the idea that you can "reason about" something that is undefined (and undefinable). Sure, historically, the original authors had some vague concept of a "portable assembler" in mind. That was a mistake that got rectified since people most definitely wanted b). We have a distinction between "implementation-defined" and "undefined."