Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The argument I have in mind is subtle and nuanced, and I didn't write clearly in that comment (the bit about the smart solo programmer was mostly sarcasm but with a grain of truth). But to try to answer:

The value of UB is to clearly document what the obligations are for valid programs. It's not valuable to indiscriminately expose that to programmers at scale without some mechanism to discharge those obligations. I don't think C's choices for UB are defensible in a modern world, and for part of that evidence see how many misconceptions there are in this thread (just to pick one, that at least some people think the move to two's complement means that signed overflow is no longer UB). On the other hand, unsafe Rust's choice to include more UB is defensible (aliasing a mutable reference is UB in unsafe Rust but not UB in C) is defensible, as it makes the whole system safer. And Odin's approach (claiming there's no UB when there actually is UB) is even worse from a "clear communication" perspective.

But maybe I should actually write the blog post some time.



    The value of UB is to clearly document what the obligations are for valid programs.
I think an argument can be made for C (where annex J exists), but this definitely doesn't apply to C++. Hence the long languishing of P1705.

I would also disagree for C though, because annex J can only cover explicit UB by definition and there's the entire category of implicit UB outside that.


Ah gotcha. Yeah it’s useful from a language perspective.

One thing I wish unsafe Rust would do, given that there’s more potential for UB in unsafe Rust than in C/C++, would be some way to enforce more compiler checks against UB you didn’t intend to stumble across but I don’t know how that would work or if it’s even possible. But Rust unsafe is decidedly sharper than C++.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: