2 ms·
I mean that's what they did, and that's why there's that UB. All I'm saying is that this is the "weird platform behaviors exist and must be legalized by the sta
by muvlon 16d ago
I mean that's what they did, and that's why there's that UB. All I'm saying is that this is the "weird platform behaviors exist and must be legalized by the standard" kind of UB and not the "we want a 0.5% win for benchmaxxing" kind of UB (the standard has plenty of both).
- fc417fc802 16d agoNo, they didn't. UB is a cop out and inserting yield is just plain bad. Locking up one or more threads in an implementation defined manner would be the outcome of least surprise (I already know it's going to lock up at least the one thread).
- mitxela 16d agoThe standards intended interpretation of UB was always intended to be something like "implementation defined, no documentation required" to allow for implementation weirdness, even unpredictable ones. It was compiler authors who decided do abuse this allowance to do really unintuitive things instead of weird platform weirdness.
- IcyWindows 16d ago100% There are implementations that have sane behavior for "UB" instead of making it an excuse to misbehave. The ISO standard is not the same as a language from a single vendor.
- mitxela 16d agoIIRC a lot of it was benchmark gaming between GCC and LLVM.
- cryptonector 16d agoBecause one can bleeping see that that's what would happen. Locking up a thread isn't a good thing, but it's a lot better than UB. There was never a need to make this UB.