Hacker News Reader

Comment by GolDDranks | Hacker News Reader

The situation is not that bad. The rules of unsafe code were pretty badly defined back then, but they are in process of becoming a lot clearer, and like the grandparent argues, with a well-defined aliasing model like Tree Borrows, they are easier to understand than C's.

If you look into the code you linked, the problem was about accessing undefined bytes though an aliased, differently-typed pointer – something you would have hard time doing in C to begin with. MaybeUninit was a new thing back then. I think that nowadays, a senior Rust developer would clear the hurdles better.

View on HN

I am very sorry, but you do not address that TBAA, like C has by default, generally is easier than just no aliasing, like what Rust has for mutable references. This is a major difference. C code can opt into a similar kind of aliasing, namely by using _restrict_, but that is opt-in, while it is always on for Rust.

And there is newer UB as well in Rust stdlib

https://github.com/rust-lang/rust/pull/139553

How is that bug in the stdlib related to any of this?

> TBAA, like C has by default, generally is easier than just no aliasing [note: I assume no aliasing here to refer Rust's mutable references, not C's restrict]

I don't accept that statement. Rust's mutable references are statically checked, so they are impossible to get wrong (modulo compiler bugs) if you aren't using unsafe code. Using raw pointers has no no-aliasing requirements, so again, it's easier than in C.

The hard part is mixing mutable references and raw pointers. In 95% of Rust code, you are not required to do that, and you shouldn't do that. In the remaining 5%, you should understand the aliasing model. In that case, indeed, you need to know more than what TBAA requires you to know. But that's for the case where you can also _DO_ more than TBAA would allow you to do.

Ycombinator/Hacker News is giving me trouble regarding replying, maybe the debate is not going the way that some people want it to go. Sad.

I think HN is (intentionally) delaying the ability to reply to deeply nested comments.

We have rate-limiters for new accounts to limit the damage that can be done by spammers, trolls and flamewar participants.

For users who have valuable contributions to make to threads and are earnest about participating positively to HN, we're happy (really, very happy) to turn off the rate limiters.

You seem to have registered multiple different accounts in order to keep participating in the thread, then hitting the rate limiters each time. Please don't do this. It's confusing for other readers and is against the guidelines [1]:

Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.

If you would like us to merge these accounts and turn off the rate-limiter, please email us at hn@ycombinator.com.

[1] https://news.ycombinator.com/newsguidelines.html

Yes, exactly. I'd be surprised if it's 5% -- that's about the ratio of all unsafe code, and most unsafe code does not mix references and raw pointers. I think it's less than 1% of the overall code that has to worry about this, but unfortunately I don't have hard data.

Agreed, I said 95% just to be generous, should've mentioned that.

Reply on news.ycombinator.com