Unsafe and memory alloc

External code is always unsafe, but also external in dynamic loaded libraries? Windows call , for example global alloc memory are in DLL. Thus memory alloc is unsafe?

I'm not sure what do you wan't to say here. Our computers made by silicon is unsafe, even our physical world is unsafe so it's totally not possible to build truely safe system from the bottom. Instead, we should build safe abstractions from those unsafe foundation - this is what we do with safe Rust.

Rust has mode "unsafe", this for example using pointers or call unsafe methods. External methods are always marked as "unsafe" in Rust?

If you are talking about ffi exported methods - yes, they are always unsafe. Also getting any pointer for dynamic function would be unsafe - there is even a crate for this, libloading, but the calls for functions loading dylib functions are unsafe.

However unsafe doesn't mean "it would burn out your computer if you call this". Sometime ffi is needed. FFI means just "because compiler cannot proof safety on its own I take responsibility for this being safe". For example C++ code:

auto a = new int;
*a = 5;
std::cout << *a <<'\n';
delete a;

is perfectly safe - but calling it from Rust would need "unsafe" mark becase rustc has no tools for proving this.

The common practice is, that if you need to use some ffi library, you create your Rust wrapper where you taking care about all constraints which should be took care of, and then exposing Rust interface which is actually safe (because in your crate you are taking care about memory/borrowing rules/transmutation/ffi types).

Good place to dig into using unsafe in safe manner is Rustonomicon.

However if you don't need to, just don't use unsfae crates, so you wont need to care about safety (which is not simple). You are talking about calls to Windows functions - there is winapi crate, check it - maybe it fulfills your needs.

1 Like

Unsafe is needed - but unsafe method is marked as unsafe and must be only called from other method also ,arked as unsafe (or unsafe block of this method)? This method must be next called from next "unsafe" method? Is unsafe propagation? But with other side - any function using Windows calls as external should be "unsafe"? It is no problem if only crates wrapping this functions are marked as "unsafe", but if unsafe propagates, all end-user methods should be unsafe? For example all allocating objects on heap, because its uses GlobalAlloc of Windows external. How break "unsafe" chain?

I'd not say you should read the book to the end before to start writing Rust code. But for unsafe, you should read the whole nomicon beforehand. It also has the answer of your question, at the first chapter.


No, unsafe does not propagate in that way. A safe method can call an unsafe method, it just needs to put it in an unsafe block, as in

fn i_am_safe() {
   let x = unsafe { scary_unsafe_function() } + 1;

This guarantees that you can look at a function an determine if it might be dangerous. If you have no unsafe blocks, then the code can't cause undefined behavior (unless it calls a different safe function that incorrectly uses unsafe code).

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.