3 ms·

Thankfully, the standard has seen fit to specify what exactly "undefined" means so you're not left to arbitrarily interpret only the bare word "undefined" in so

Thankfully, the standard has seen fit to specify what exactly "undefined" means so you're not left to arbitrarily interpret only the bare word "undefined" in some sort of "layman" way.

hansvm 3y ago
Unthankfully, the definition is so vague as to be totally useless from a programming perspective. Avoid invoking UB, or all hell breaks loose. [0] Separately, I don't think their point was that they were speaking as a layman, but rather that the loose definition they gave is historically accurate, easier to reason about, and what a working programmer not versed in the nuances of UB would expect. The fact that UB has its current definition is indicative of "undefined [getting] lost somewhere." [0] https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior...
- deleted 3y ago
  [deleted]
- taway1237 3y ago
  The definition is pretty precise, compiler can do whatever it wants with UB. That's not very helpful or useful, but the standard is very explicit about that.
- mike_hock 3y ago
  > 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."

Thankfully, the standard has seen fit to specify what exactly "undefined" means so you're not left to arbitrarily interpret only the bare word "undefined" in some sort of "layman" way.

hansvm 3y ago

Unthankfully, the definition is so vague as to be totally useless from a programming perspective. Avoid invoking UB, or all hell breaks loose. [0] Separately, I don't think their point was that they were speaking as a layman, but rather that the loose definition they gave is historically accurate, easier to reason about, and what a working programmer not versed in the nuances of UB would expect. The fact that UB has its current definition is indicative of "undefined [getting] lost somewhere." [0] https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior...

deleted 3y ago
[deleted]
taway1237 3y ago
The definition is pretty precise, compiler can do whatever it wants with UB. That's not very helpful or useful, but the standard is very explicit about that.
mike_hock 3y ago
> 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."