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

Minor nitpick, at the end of the article:

  Sure, it does some risky pointer math, but that’s considered safe in Rust.  
I wouldn't fully agree to that, from The Rust Programming Language book [1]:

  Much of Rust’s safety comes from compile-time checks, but raw pointers don’t have such guarantees, and are unsafe to use.
[1] https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...


I am Rust newbie myself, but I don't understand how this could be considered safe:

    strict::with_metadata_of(new_ptr, self.shared.as_ptr() as *mut T)
I always thought pointer math was considered safe because math is safe. Which is fair enough, as adds and subtractions can't do much beyond overflow. What is unsafe is accessing the memory location using the result of that math, as the result could point anywhere.

They don't do that (access memory using the raw pointer) here. But if anything what does happen is worse: raw pointer that is considered unsafe to use is cast back to a typed pointer that is considered safe to use, and returned to the unsuspecting caller.

I'm scratching my head on why strict::with_metadata_of() isn't marked as unsafe. In the example the standard library documentation gives https://doc.rust-lang.org/std/primitive.pointer.html#method.... it is wrapped in unsafe{}.


I'm not that deep into rust, especially unsafe rust, either. But I'm not really sure where the strict:: comes from? If it is the same function from the standard library then I'd put my money towards "its probably meant to be unsafe, but hasn't been marked as such yet. The function is still considered unstable and is only available on the nightly compiler".


with_metadata_of returns a raw pointer, which is not safe to use.


Thanks for taking the time to point out the obvious to a newbie.

Now, that's apparent the point of the article isn't so clear. The point looks to revolve around this line:

> Eagle-eyed readers might have noticed that this code has no unsafe. Not even a line.

That statement is not really true, as the return type (*T) implies the method is unsafe.

Oh well, it was an interesting bug hunt story.




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

Search: