Re:Zlib-rs is faster than C
by steveklabnik on Sunday March 16, 2025 @05:18PM
(#43382404)
> allows you
This is where the rubber hits the road. Rust does not allow you to do this, in the sense that this is possibly undefined behavior. That "possibly" is why the compiler allows you to write this code, because by saying "unsafe", you are promising that this specific arbitrary address is legal for you to write to. But that doesn't mean that it's always legal to do so.
Re:Zlib-rs is faster than C
by timschmidt on Sunday March 16, 2025 @05:23PM
(#43382457)
The compiler won't allow you to compile such code without the unsafe. The unsafe is *you* promising the compiler that *you* have checked to ensure that the address will always be legal. So that the compiler will allow you to compile the code.
Re:Zlib-rs is faster than C
by steveklabnik on Sunday March 16, 2025 @05:24PM
(#43382475)
Right, I'm saying "allow" has two different connotations, and only one of them, the one that you're talking about, applies.
Re:Zlib-rs is faster than C
by timschmidt on Sunday March 16, 2025 @05:37PM
(#43382596)
I gotcha. I misread and misunderstood. Yes, we agree.
So, in theory, unsafe rust opens the floodgates. In practice, though, you can use small fragments of unsafe code that programmers can fairly easily check to be safe.
Then, once you’ve convinced yourself that those fragments are safe, you can be assured that your whole program is safe (using ‘safe’ in the rust sense, of course)
So, there may be some small islands of unsafe code that require extra attention from the programmer, but that should be just a tiny fraction of all lines, and you should be able to verify those islands in isolation.