4 ms·

> It may have started this way in the committee (though that isn't true for e.g. type based alias rules), but nowadays it's depended on for performance. You los

> It may have started this way in the committee (though that isn't true for e.g. type based alias rules), but nowadays it's depended on for performance. You lose a lot of ability to reason about loop trip count if signed overflow is defined, for example. I agree it is depended on in many cases, and should not be. That is on the programmers though, not the language designers. The behavior does not exist to cover deficiencies in the language but those of its users. > The probability that a program depends on any of (nonexhaustive list) (a) inspecting the value of a dangling pointer; (b) taking the offset from NULL; (c) type-punning through a union; (d) type-punning through any type other than char; (e) signed overflow; (f) order of operations between sequence points quickly approaches 1. Just on your short list I can tell you the probably of any of our C code depending on that approached zero: > inspecting the value of a dangling pointer Our code was malloc once, free never. Dangling pointers were by definition impossible. > taking the offset from NULL > type-punning through a union > type-punning through any type other than char > signed overflow > order of operations between sequence points Our coding standards covered all of those, so their existence would be a code review failure. We weren't specifically writing to MISRA C, but I will wager that your statement is not accurate for any project that follows it or any similar standard. Yes, it is a lot of work that you don't need to do with a more controlled and less flexible language. I'm not going to challenge that. I'm just challenging the idea that nobody is writing C that avoids undefined behavior.

catnaroek 10y ago
> Our code was malloc once, free never. Dangling pointers were by definition impossible. Dangling pointers can arise in other ways: use an uninitialized pointer variable, take the wrong offset from an otherwise valid pointer, etc.
- vonmoltke 10y ago
  Those are indeterminate values but they aren't dangling pointers. Dangling pointers are specifically references to an object that has been freed. Plus, the cases you highlighted are programming errors, not reliance on undefined behavior.

catnaroek 10y ago

> Our code was malloc once, free never. Dangling pointers were by definition impossible. Dangling pointers can arise in other ways: use an uninitialized pointer variable, take the wrong offset from an otherwise valid pointer, etc.

vonmoltke 10y ago
Those are indeterminate values but they aren't dangling pointers. Dangling pointers are specifically references to an object that has been freed. Plus, the cases you highlighted are programming errors, not reliance on undefined behavior.