[felipetrz]

The whole point of explicit unsafe rust is making this type of thing have to be written on purpose. You can't accidentally write unsafe code. And in case you accidentally write unsound code in your explicit unsafe code, you know exactly where to look.

[pjmlp]

While I agree in principle, the fallacy from security point of view, is assuming it was the same person, or that the error happened in unsafe code block and not elsewhere, caused by wrong invariants.

Hence coding in a safer language by itself isn't a guarantee, care must still be taken.

Still better than C language family anyway.

[tialaramex]

> that the error happened in unsafe code block and not elsewhere

Remember Rust's Safety Culture, the big C word I mention over and over here and elsewhere that we run into each other? Although the Rust compiler doesn't get to have an opinion about this, Rust's culture does, and Rust says no, the error is in your unsafe block.

Suppose I write a function which takes six 8-bit unsigned integers A, B, C, D, E and F, adds them together and then indexes into an array I own which is 512 entries long. Clearly if you give me most possible values of A through F this is a bounds miss.

If I write this function in safe Rust, it panics when you do that. The bug is in my code, that's where the panic happens.

If I write it in C, it blows up when you do that, but, and here's the crucial part, maybe I say "Idiot, the documentation clearly says in paragraph six see value normality subsection B4, and in B4 I wrote that none of A through F should have values such that when added they sum to 512 or more, thus it's your fault.

If I write it in unsafe Rust then culturally I have two clear choices. One of them is like the C. I write my very extensive documentation and I mark my function unsafe which indicates that callers need to read and understand the documentation to ensure they obey all pre-conditions. Their code will also be unsafe because they can't call my unsafe function without that, reminding them of their responsibility.

The other choice, which is more usual, is to safely encapsulate the feature. I can optionally write extensive documentation, but regardless I must ensure the function cannot cause unsafety even if used by a malicious idiot.

Because of these two options, the problem is always the unsafe code. Maybe it's my unsafe code (I did a bad job either obeying or specifying the preconditions) or maybe it's your unsafe code (you didn't obey my preconditions) but either way it's never the safe code.

Rust's compiler can't promise that but Rust's culture can.

[pjmlp]

The culture part I agree on, certainly.

Something shared on Java and .NET land, when discussing JNI, P/Invoke, C++/CLI.