Shower thoughts: Since virtually every C/C++ program relies on undefined behavior somewhere (e.g. dlsym casts between void */void (*)(), BSD sockets), there have basically never been miscompilation bugs in the wild, technically speaking.
19
34
246
Conversation
Replying to
this is funny but the actual situation is also funny: all real C and C++ applications are written in a non-standardized, undocumented programming language that closely resembles standard C and C++ but has less undefined behavior
6
12
139
It's mostly that, but it happens the other way around to some extent too.
Compilers sometimes decide they should be able to do something and the standard is overly permissive. Then, eventually, maybe the standard gets aligned to what compilers actually felt like doing.
1
1
do you have a list of examples? I think this is rarer! or I hope so
3
Since that’s the thing sticking out to me I think rare is the right word
1
1
I think it's quite rare for anything significant / prominent but I don't think it's rare for subtle things. They often add text saying something is undefined, when previously it was glossed over, poorly defined or implementations just screwed it up and did broken things.
I just find it quite odd for something to be 'clarified' as making your entire program invalid, because it was previously glossed over. A lot of type punning, infinite loop stuff and now trying to standardize pointer provenance is basically retroactively allowing optimizations.
1
2
Compilers consider some optimization important enough to do it even if it's somewhat wrong or not allowed. They do it. Standard catches up and gives them the wording they need to do it. This kind of thing isn't particularly common, but they actually do this in prominent ways.
1
2
Show replies