6 ms·
For your last point, the extent of UB driven changes to semantics is still not widely known in the programmer community. Programmers don't read the standard - t
by vyodaiken 5y ago
For your last point, the extent of UB driven changes to semantics is still not widely known in the programmer community. Programmers don't read the standard - they read K&R, and K&R is right now describing a different language. We've had 15 years of programmers repeatedly filing bug reports to be told that the expected, tested, relied on, behavior was ephemeral. Only very sophisticated projects figure out about UB.
Of course compilers have to make assumptions. The debate is (a) over what assumptions it is proper to make and (b) what are the permissible behaviors. The false dichotomy: either do without any optimizations at all or accept whatever UB gives you, is not a useful approach.
- MauranKilom 5y agoSo what optimizations do you mean with "these UB optimizations" then? And would it change your mind to see a benchmark proving the usefulness of that particular UB optimization?
- vyodaiken 5y agoe.g. assuming UB can't happen: deleting overflow or null pointer checks, deleting comparisons between pointers that are assumed to point at different objects, ...
- Dylan16807 5y agoI'm surprised you don't think deleting a bunch of checks will improve performance.
- a1369209993 5y ago> So what optimizations do you mean with "these UB optimizations" then? Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour.