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
I have some examples. I'd need to think about it to actually list some of them out.
Happens with the standard library pretty commonly too, even with the most basic APIs like malloc/realloc/free.
It's often the kind of stuff they deal with via defect reports.
1
4
The malloc stuff is what I've had to deal with myself. They've gone back and forth about whether certain things are allowed and how they're defined, like realloc with size 0, aligned_alloc with an alignment that's not a multiple of the size and several other things for those.
1
4
Does realloc(p, 0) do the equivalent of malloc(0) and then frees p if successful? Does it simply free p? Is it undefined? Who even knows anymore, because they changed it too many times (literally at least 3 times) and while I think it's undefined now it's very commonly used...
3
3
There are some good examples in open-std.org/jtc1/sc22/wg14 and other defect reports / resolutions.
It's quite annoying in between the DR changing it and the next C standard shipping that new wording because the implementations seem to largely ignore DRs resolving stuff afterwards.