The rabbit hole of unsafe Rust bugs

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{}.

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.

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.

Unsafe code can act on inputs provided from safe code.

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.

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.

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.