Thank you to those who continue to develop Miri. It is a great tool for those of us that have crates that need to use unsafe. While nothing will give 100% confidence in the lack of UB, Miri is a great start.

I have just been subjected to a Paradox Exception caused by reading that the memory safe Rust language has and can cause undefined behaviour. My spatial location code in the Universe has been marked with a Time-Space::Paradox violation and is awaiting debugging by celestial dev-ops. Luckily I am currently a live process, so my space and memory will not at this time be reclaimed by the Global-Universal Operating System.

If you have a codebase that uses unsafe, I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out.

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++.

I used Miri for some key deno libraries and spent a fair bit of time cleaning up the violations. Many of them were real unsoundness bugs due to reference aliasing.

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.