Only unsafe blocks can cause undefined behavior. The memory safe portion of Rust that most program in cannot cause UB. If you use "forbid unsafe" then you can be assured your program is free from UB (assuming all the crates and stdlib you use are as well).
I ran tests for a codebase at work through Miri a while ago and found a couple of distinct classes of UB: https://github.com/rust-lang/miri/issues/1807#issuecomment-8...
These can be summarized as:
1. Converting a reference to the first field of a struct to a pointer of its parents struct type
2. Functions with signature (&self) -> &mut self_inner_field_type
3. Having a mut pointer to the data inside of a Box<T>
#1 and #3 were somewhat surprising to me. #2 seems to be common enough that there's even a clippy lint for it.
A lot of C and C++ developers understand that undefined behavior is bad, but in practice observe its impact less. From my own experience, Rust's optimizations are pretty aggressive and tend to surface UB in way more observable ways than in C or C++.
...which is great. In C++, the compiler has to be cautious due to unpredictable side effects of damn near everything, i.e. it can hardly assume that any data is unaffected across most function calls.
Unsafe code absolutely needs Miri if the code paths are testable. If not all code is Miri-compatible, it's worth restructuring it so you can Miri test as much as possible.
Note that Miri, Valgrid and the LLVM sanitizers all compliment each other and it's really worth adding all of them to a project if you can.
When I have Rust projects with subsystems that must be unsafe, I will design them around Miri testability. This mostly means writing small unit-testable units and isolating I/O as much as possible. I almost always find I have made mistakes that Miri catches.
nu11ptr•1mo ago