Ambiguity of "unsafe" causes confusion in understanding

[AndrewGaspar]

You can define a new wrapper function that just passes arguments blindly from the “wrapper” to the target function, but you’ve introduced unsafety into the program: you’ve violated the memory safety semantics of Rust. See what I said above:

You MUST NOT allow the possibility of memory unsafety to leak outside of the unsafe block.

So, your hypothetical WRAP_CreateWindowExA function should also be marked as unsafe - a caller could violate memory safety by passing in certain arguments.

A safe wrapper for CreateWindowExA would be something ala:

fn create_window(class_name: &str, ...) -> Window {
    let null_terminated_class_name = CString::new(class_name).unwrap();

    unsafe {
        Window::from_raw(CreateWindowExA(
            0, // default window type
            null_terminated_class_name.as_ptr(), // This is memory safe now - class_name has been null terminated!
            ...))
    }
}

[AndrewGaspar]

It introduces a further level of calling, which loses performance.

Generally don’t worry about this in Rust (or any other compiled language with a modern compiler). The compiler will inline the call if it’s worth it, it won’t if it’s not worth it. Only worry about function call overhead if you’ve actually benchmarked and examined the compiler output and decided the whole construct needs to be in-lined in-source. Otherwise it’s premature optimization.

[vitalyd]

@senator, it might help to think of “unsafe” as simply: compiler cannot enforce the memory safety guarantees, for whatever reason - it’s on you, the author, to do it manually.

With FFI, the reason is fairly obvious - you’re calling into a black box the compiler has no knowledge of.

With unsafe traits, it’s a matter of the compiler (or the language) not being able to express the requirement. For instance, the Sync marker trait; compiler will auto-implement this for compound types if their innards are Sync but sometimes you’ll need to do this yourself (eg you hold raw ptrs to FFI structures). It’s again similar in that the compiler cannot see into foreign code.

std::io::Read::initializer() is another interesting case, but ultimately boils down to the same thing: compiler cannot see into an opaque black box. The gist here is you’ll likely end up calling some FFI code (eg libc to a syscall) to perform the actual read I/O.

Most, if not all, unsafety stems from the “simple” fact the compiler ultimately cannot see things.

[ibkev]

I’ve always wished instead of the “unsafe” keyword, the designers had chosen “unchecked”. ie. unchecked by the compiler and (hopefully) confirmed safe by other means.

There’s quite a lot of safety critical C code out there whose designers would bristle at the idea their code is unsafe. Especially since there’re plenty of programming/logic errors that can still exist in code that is safe by Rust’s strict definition of the term. To me, “unsafe” implies a value judgement that is both unjustified and can lead to dogmatic thinking (similar to how some people like to declare language features to be “evil” without reference to the underlying engineering tradeoffs.)

[HadrienG]

That is actually the naming convention which Ada uses, so there is prior art in this direction On the other hand, speaking personally as a heavy user of unsafe code, I am quite happy that Rust uses the “unsafe” terminology, for the following reasons:

• It directly relates to the underlying concepts of memory-safety, type-safety and thread-safety, and there is a lot of prior art for calling languages which guarantee these properties “safe languages”.
• It puts a big red scary warning on something which people should find scary and avoid whenever there is a reasonable alternative (who wants to debug undefined behaviour in 2018?).
• For similar reasons, it attracts attention during code review, which is good because manually checked code must also be manually verified by others.

[gbutler69]

To me, the issue is not so much “unsafe” as THE keyword vs. something else like “unchecked”, “unverified”, “whatever”; as it is the difference between “declaring an unsafe contract” vs “implementing code which must uphold invariants of unsafe contracts”. To me, using the same word for both sides of this causes confusion with the overall concept of “unsafe”. That is why I suggested something like:

• When declaring/defining “unsafe” contracts (like functions and traits):
  • trait - “unsafe contract trait …”
  • func - “unsafe contract fn …”
  • external/FFI - “unsafe contract external fn”
• When using/implementing/calling something that defines an unsafe contract:
  • trait - “impl unsafe contract honored trait … for …”
  • unsafe block - “unsafe contract honored { … }”

Something like this makes absolutely clear the distinction between defining and unsafe contract and code that must uphold the implied contract.

To my mind this would likely result in a lot less confusion for those learning Rust and would make the overall “unsafe” story much more coherent.

What I proposed, is kind of verbose, but, verbosity WRT unsafe probably is a feature not a bug.

[HadrienG]

There was a discussion about this on internals some time ago. One comment was that there is actually a third dimension to unsafe in current usage, which was “properties that unsafe code can rely on” . Think traits like Send and Sync, or TrustedLenIter.

These require special care since unsafe code is not normally allowed to trust safe code (e.g. relying on Eq to be reflexive and transitive for memory safety is a bug). Currently, they are also annotated using unsafe.

To clarify this, one could speak of “unsafe preconditions” (user must provide these for memory safety) and “unsafe postconditions” (user can rely on these for memory safety). And keep unsafe blocks for manually checked code regions. The idea would be that you need to use an unsafe block in order to do anything potentially unsafe, including calling a function with an unsafe precondition, or returning from a function with an unsafe postcondition. Shorthands would be easy to find: “unsafe pre/post” .

This distinction would solve some longstanding problems with unsafe, for example the fact that you need an unsafe block to implement an unsafe fn (this is not necessary if that unsafe is linked to a precondition: you may not use the precondition in your code). It could also be gradually introduced in existing code, by first making the pre/post annotations optional, then later making them mandatory.

Is this truly necessary at this stage of Rust’s evolution, though, considering the amount of churn involved for existing code? I would not know…

[HadrienG]

I just tried to turn this into a Pre-RFC just to check what others think about it. Feel free to chime in! https://internals.rust-lang.org/t/pre-rfc-another-take-at-clarifying-unsafe-semantics/7041

[jimuazu]

Perhaps “trustme” instead of “unsafe”? “unchecked” also makes sense. But really once you “get it”, it doesn’t matter quite so much. It’s just during the learning process.

[Pauan]

I would be okay with having two different keywords, however…

New users shouldn’t even be aware that unsafe exists. Even experienced Rust programmers should rarely use unsafe.

After reading your example thread, I think the issue isn’t with the unsafe keyword, the issue is a misunderstanding of the entire concept of unsafety in Rust.

As others have pointed out in that thread, unsafe isn’t a “lint” that you can just turn off and ignore. It’s rarely appropriate to call C APIs directly without any sort of conversion or checking.

Writing safe wrappers for unsafe code is idiomatic and highly recommended, but those wrappers need to carefully guarantee that the code is safe (by using conversions, checks, or programmer knowledge). Writing correct unsafe code is difficult, and requires advanced knowledge of Rust.

Therefore, I think changing the keyword won’t fix the problem at all. Instead, the solution is to have better documentation that explains what unsafe means, and how to write correct unsafe code. Perhaps it would be good to have unsafe functions in the documentation automatically provide a link to the Book.

[vitalyd]

Therefore, I think changing the keyword won’t fix the problem at all. Instead, the solution is to have better documentation that explains what unsafe means, and how to write correct unsafe code.

Precisely my thinking as well. You can use any keyword you want, terse or verbose - if the concept, rules, docs and so on aren’t up to snuff, it won’t matter. It’s like C++11 memory order variants - they have different names for different semantics but the semantics require elaborate explanation; the names are just familiar mnemonics to use once the semantics are understood.

[gbutler69]

I agree. The more this gets debated the more I’m convinced that changing or otherwise supplementing the “unsafe” keyword will accomplish nothing. In fact, it seems like even people who are suggesting differing keywords seem to have rather circuitous arguments that don’t seem to be grounded in a clear understanding of what unsafe vs undefined behavior vs wrapping unsafe code is. I think you all are correct. The thing that is needed is more explanation of unsafe with specific examples, etc.

[H2CO3]

There’s quite a lot of safety critical C code out there whose designers would bristle at the idea their code is unsafe.

The sad reality is that all C code is unsafe, because C doesn’t have enforced automatic exhaustive memory safety checking. So indeed, however upset those developers might be, the code they write is still unsafe all the way around.

You appear to be confusing “unsafe” with “has a memory management bug”. There may be pieces of unsafe code that do not actually have a memory management bug. In fact, we want (and hope) that no pieces of unsafe code have memory management bugs. Still, this doesn’t practically rule out the possibility of the existence of such bugs.

All in all, unsafe means “this could potentially have a memory management bug if written or changed without enough caution”, and not “this definitely/unconditionally has a memory management bug”.

[H2CO3]

It still does not help reducing any unsafety,

It absolutely does — that’s the whole point of writing a safe wrapper around an unsafe function. The wrapper can validate the parameters, dynamically ensure all other kinds of invariants which are necessary for the call to the underlying unsafe function to always be correct, and only then call the function. This is a fundamental kind and use of abstraction in Rust.

[H2CO3]

Please, let’s not add more keywords for the same concept. I think it would only cause more confusion. I still remember when I first learned about unsafe in Rust — and it wasn’t anything remotely hard to understand, but I would have found it pretty annoying if I had had to memorize two different keywords instead of one.

This is because unsafe actually has one very clear and specific meaning: “doing this is dangerous because many of Rust’s safety rules are not enforced”.

Now the “doing this” part can be different – it can be an FFI function call, it can be dereferencing a raw pointer, it can be the creation of a string from bytes that are not verified to be UTF-8, it can be any expression, really. But exactly what kind of expression is unsafe doesn’t really matter — it’s the same concept all the way down. An unsafe function is unsafe because it requires preconditions that the compiler can’t verify. This is true whether you are implementing the function, “looking from the inside out”, or calling it, “looking from the outside in”.

And an unsafe block communicates the identical issue, too: “there’s stuff in this block that is not verified by the compiler, so you need to be extra careful”.

I don’t think there’s a fundamental difference between function declarations, calls to unsafe functions, or any other unsafe expression in this regard – they are two (or three, or however many you can think of) aspects of the exact same issue: the compiler averts its eyes and lets you do several dangerous things.

[gbutler69]

I’ve come to agree that adding to or changing the “unsafe” keyword will not help in the understanding of the concept; however, I disagree that declaring unsafe traits and functions is the same as implementing unsafe traits and calling unsafe functions (dereferencing a pointer can really be thought of as calling and unsafe function as well, it’s just a function that is built-in/intrinsic to the compiler).

The only reason I suggested perhaps adding differentiation for these cases was because of this confusion that seems to be apparent with those new to Rust. They tend to (based on questions and threads I’ve seen like the one I pointed to) that an “unsafe” function needs to be called from inside an “unsafe” block so that the compiler won’t complain rather than understanding that the “unsafe” function has pre-conditions/post-conditions that must be upheld by the caller and that putting it inside and “unsafe” block is your way of letting the compiler know, “Yes, I know there is an unsafe contract to uphold here, and yes, I have in fact done the necessary work to uphold that contract, so, you can allow me to call this function that has an unsafe contract”. More importantly, just putting it inside an “unsafe” block so that the compiler won’t complain, without understanding and upholding the necessary contracts, is not accomplishing anything except for creating code that will more than likely exhibit undefined behavior and likely have security and correctness issues.

The important point that I thought might be possible to solidify in the minds of newbies with the differentiation was exactly this. But, after reading the responses to this thread (and other threads spun off from it), I’m skeptical that any combination of keywords will be any better than just “unsafe”.

[gbutler69]

the compiler averts its eyes and lets you do whatever you want.

This is something that I think is the exact wrong message about unsafe. Importantly, it isn’t true. “unsafe” does not allow anything. It allows 4 specific things that are otherwise not allowed:

• dereferencing raw pointers
• calling “unsafe” functions
• implementing “unsafe” traits
• accessing a mutable static (aka Global) variable

Yes, technically, because you can call an “unsafe” function and dereferencing a raw pointer can do arbitrary things, it is somewhat true that “unsafe” allows anything, but, that is not the point. Interestingly, things like borrow checking continue to function even inside unsafe blocks. All other compiler checks are upheld as well.

Again, the important thing to solidify in the minds of newbies is:

• inside an unsafe block, if you call an unsafe function, you must ensure you’ve done whatever is necessary to uphold the pre-conditions of that function; otherwise, you could and likely will have undefined behavior. Also, if you are calling an “unsafe” function, that function must be well-behaved as long as its pre-conditions are met; otherwise, that function is buggy.
• if you dereference a raw pointer, you must have ensured prior to that that the pointer does in fact point to accessible memory that is initialized with the appropriate content and at the appropriate alignment for the data-type you are dereferencing to. If not, it will be undefined behavior
• if you access read or write to a mutable static variable, you must ensure that either you are the only thread doing that (guaranteed), or that you have done appropriate synchronization by using something like mutex.
• if you implement an unsafe trait for your struct, you must ensure that the combination of fields on your struct and their access modifiers guarantee that it is not possible, through any combination of current or future safe traits, to violate the contract requirements of that unsafe trait

[H2CO3]

I have amended the wording in my response – but I feel that is splitting hair and I don’t think the exact phrasing is the point (or was in what I wrote).

[gbutler69]

Yes, but, in this case, it is really important for clarity to split the hairs (IMHO). But, please, don’t take anything I said as a criticism of what you said. More of an amplification/clarification.

[dobkeratops]

To be absolutely clear it would have to be a longer word

potentially_unsafe

You can’t say “verified”, because the compiler doesn’t know that - thats the whole point.

I think ‘unsafe’ is fine. it draws attention and people will ask what it means