3 ms·
This is a cool summary of UB, but speaking to the title... Well yeah. Did anyone suggest otherwise?
by hot_gril 3y ago
This is a cool summary of UB, but speaking to the title... Well yeah. Did anyone suggest otherwise?
- philosopher1234 3y agoTo me this article is interesting because * it is thorough, detailed and very thoughtful * rsc’s essays usually end up with a major Go language change, so there’s a good chance this article is the seed of some change to Go and undefined behavior, or correctness or performance. Even if it’s not a major upcoming change (I bet it is, tho) rsc is an extremely insightful dev.
- hot_gril 3y agoYeah, I agree. I was editing my comment to praise the article's body as you were replying.
- rsc 3y agoThere is no major upcoming Go change related to this post. This is just a much longer version of https://research.swtch.com/plmm#ub https://research.swtch.com/plmm#ub that I drafted years ago and finally cleaned up enough to post.
- philosopher1234 3y agoIt’s fine, I’m not sad or anything
- uecker 3y agoIt should be "C and C++ Implementations" because nothing in the standard requires UB to be exploited for optimization instead of adding run-time checks.
- hot_gril 3y agoThe standard also doesn't require UB to have run-time checks, which is probably for the goal of performance. There was an implementation in mind when it was designed.
- uecker 3y agoThere were C implementations with bounds checking or implementations that trap on use of an invalid pointer or on read of uninitialized variables etc. A large part of UB was introduced for such reasons and not for performance. The standard was (and still is) about allowing a wide range of implementations.
- SenAnder 3y agoA periodic reminder is good.