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.
Dangling pointers can arise in other ways: use an uninitialized pointer variable, take the wrong offset from an otherwise valid pointer, etc.
Plus, the cases you highlighted are programming errors, not reliance on undefined behavior.
(b) True. I think this one should be defined and standardized.
(c) It seems that C99 defined this behaviour. https://stackoverflow.com/questions/11639947/is-type-punning...
(d) I am not knowledgeable enough. Could you give an example?
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.
> Citation needed. I get that undefined behavior is hard to spot, but having spent years writing cross-platform C I cannot accept that every large program depends on it without some evidence.
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.
Here's a very interesting survey investigating this: https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-survey-disc...