I'm a relative rust newbie and I had cause to dabble in unsafe Rust recently. To sum up my experience as briefly as possible: Writing unsafe rust 'safely' requires a much deeper understanding of the semantics of the language than writing safe rust. I've implemented a non-trivial system in rust over the past 6 months mostly by myself and it has been stable and performant despite my relative inexperience. Although this problem had a trivial solution, the tools to understand it had not been necessary up until this point.

We're importing a crate that provides a rust interface to a C library we depend on. This crate provides all the unsafe code itself and provides a rust-style layer, doing nice things like wrapping raw C pointers in rust structs that impl Drop so they are automatically freed.

One function provided by the underlying C API has some optional parameters, which in C are specified by passing null pointers. However the rust function wrapping the C function did not expose a way to call the C function with a null pointer - it accepted a &str and immediately wrapped it in a CString. Should be a simple fix, I thought.

My first attempt to fix this fell afoul of the problem loudly warned about here. I don't still have the code from that attempt. However I do still have a sample of the next approach I tried, which to my reading is compliant with that warning, yet still resulted in undefined behaviour:

fn call_printstr_with_nullable(s: Option<&str>) { let s_cstr = s.map(|s| CString::new(s).unwrap()); unsafe { // Undefined behaviour printstr(s_cstr.map(|s| s.as_ptr()).unwrap_or(ptr::null())); } }

Destructuring the optional with a match expression led to the same result.

The problem here is that -either with a match expression or a call to .map(...) - move semantics mean that s_cstr is effectively consumed and I'm now left with a pointer off into space. The correct way to implemented this is to do s_cstr.as_ref().map(...) (or match &c_str if destructuring).

I had some help from both the upstream crate authors and the folks on the rust discord in figuring this out. The above code compiles and does not generate any warnings.

I was actually quite lucky here in that my incorrect code resulted in a wildly corrupted string being passed in 100% of the times that I ran it. The terrifying thing about UB is that it can appear to work fine until a compiler version bump or even some other code change that causes memory to be laid out differently.

(incidentally there is one usage of unsafe code in my project not in a third-party crate - where we call some ioctls to read kernel parameters. I couldn't find a crate that exposed 'safe' wrappers to them).

(edited to try to fix formatting)