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.

> a bug in safe code can easily cause unsound behavior in your unsafe code if you’re not careful.

I thought the whole point of safe code was that any bugs in safe code cannot cause unsound behaivor, so it's on the unsafe code to maintain soundness even if it's used incorrectly by safe code?

Calling an unsafe function means "I promise to uphold the invariants required" and often that requires writing safe code a certain way.

For example, in WGPU I get the surface of an OS window. This requires an unsafe function call. The invariant I must uphold is to not drop the window before the surface. This requires writing my safe code a certain way. And indeed, a malicious actor could change only safe code and cause UB by dropping the window (I believe this would cause a double free when the surface is dropped). However, the struct holding the window and surface presents a safe API to users of the struct, and no code outside the struct can cause UB.

If you're writing unsafe code meant to be used by safe code, the safety boundary is usually at the interface level (i.e. public functions not marked unsafe), not necessarily just the unsafe {} construct. So there's 'safe code' that only uses safe interfaces and should be memory safe whatever it does, there's unsafe code which explicitly opts into the unsafe operations where memory safety issues can occur, and code in the middle which is not marked unsafe but still needs to uphold invariants the unsafe code depends on. As a rule of thumb if you've got unsafe in library code, the entire module (which is the public/private boundary) may have an impact on safety.

I see, I suppose that kind of makes sense and is good enough. Maybe it would be nice to be able to mark fields / variables with critical invariants as unsafe, so that only unsafe code change them?

Safe code can invalidate invariants of unsafe code in block containing perfectly safe code.

Famous example is:

    impl Vec {
       pub unsafe fn set_capacity(&mut self, capacity: usize) {

          self.capacity = capacity; // why is that unsafe? 
       }

    }

What OP possibly did was invalidate his invariants in safe code.

Yes; that's the whole point. There is even a computer verified proof that (for some version of std) if you only use the standard library and don't use unsafe, then you can't write a program that exhibits unsound behavior.

Of course, if there's one bug in unsafe code, then all bets are off, but that's still a bug in the unsafe code.

I think the "It’s not unsound; it’s not even incorrect." is wrong... Clearly, it's unsound -- the problem in this post was documented[0] as a safety precondition of the one function they call in that block!

In code I'd consider high-quality, there'd be a comment like this [1]:

    // SAFETY: inner is only mutated by foo, bar, and baz, all of which
    // ensure the pointer is valid.

[0]: https://doc.rust-lang.org/std/primitive.pointer.html#method....

[1]: https://std-dev-guide.rust-lang.org/policy/safety-comments.h...

[0] has an unsafe annotation, so in order to invoke it, you have to write the token "unsafe", which means all bets are off unless some sort of external proof of soundness exists.

The "It's" in the quote (from the article) was referring to a particular snippet in the article, not the .as_ref() method.

Unsafe code can act on inputs provided from safe code.

I wonder if it would be interesting to introduce a "safe" annotation to Rust, which would fail compilation if any code the function calls is unsafe.

You can use #![deny(unsafe_code)] in your own code.

If you're hoping to enforce across all called functions, it's likely to be unworkable since a lot of stdlib ends up calling unsafe code.

Or even stronger

    #![forbid(unsafe_code)]

Then it can't be `#[allow()]`ed.

There's also things like `cargo gieger` that will tell you how much unsafe code your dependencies have.

I think you meant `cargo geiger`

TIL forbid(), thanks!

Are there examples where unsafe Rust is a must?

Sure. Accessing C FFI. Calling low level code like asm!, SIMD and so on.

You'll never be able to truly escape it, just mostly. -- One interesting suggestion by matthieum on Reddit was to make previously safe fn unsafe.

DMA, because the buffer can be linked to a designated RAM section, and it needs to be declared as a static mutable.

There would be many examples when code is running at lower levels with no OS abstraction

The 3rd paragraph has 3 bullet points about it.

I know, but I'd like to read some input from the HN crowd aswell.

There quite a few APIs which do not have safe wrappers. Recently I needed to disable IP fragmentation on a socket. I had to invoke the raw c library which is unsafe.