I think one of the best attempts to solve this is the attempt to classify undefined behavior into "bounded" and "critical" UB, which is a distinction that hasn't gained as much traction as I'd like.
Something like 1<<32 is "bounded" UB, and can't result in anything happening to your program... it is permitted to result indeterminate values, it is permitted to trap, but that's basically it.
Critical UB is stuff like writing to a const object, calling a function pointer after casting it to an incompatible type, dereferencing an invalid pointer, etc. Basically, anything goes.
This is part of the "analyzability" optional extension which I wish would gain more traction.
> Something like 1<<32 is "bounded" UB, and can't result in anything happening to your program... it is permitted to result indeterminate values, it is permitted to trap, but that's basically it.
That is what implementation-defined behavior is for. Feel free to advocate for changing the standard accordingly.
> Feel free to advocate for changing the standard accordingly.
I am, in fact, describing the existing C standard, not advocating for changes. Please refer to Annex L "Analyzability", which defines the terms I used: "bounded undefined behavior" and "critical undefined behavior". Note that this section is conditional... it is not widely adopted. I am advocating for increased adoption of this part of the standard, or barring that, revisions that would make adoption more palatable.
And in general, "If you don't like it, advocate changing the standard" is not a useful or insightful response. It is completely reasonable and normal to complain about something without trying to fix it.
Something like 1<<32 is "bounded" UB, and can't result in anything happening to your program... it is permitted to result indeterminate values, it is permitted to trap, but that's basically it.
Critical UB is stuff like writing to a const object, calling a function pointer after casting it to an incompatible type, dereferencing an invalid pointer, etc. Basically, anything goes.
This is part of the "analyzability" optional extension which I wish would gain more traction.