Miri: Practical Undefined Behavior Detection for Rust [pdf]
Posted5d agoActive16h ago
research.ralfj.deResearchstory
informativepositive
Debate
10/100
RustUndefined BehaviorAI Performance Analysis
Key topics
Rust
Undefined Behavior
AI Performance Analysis
Discussion Activity
Moderate engagementFirst comment
5d
Peak period
9
108-120h
Avg / period
5
Key moments
- 01Story posted
Dec 28, 2025 at 3:24 PM EST
5d ago
Step 01 - 02First comment
Jan 2, 2026 at 1:52 PM EST
5d after posting
Step 02 - 03Peak activity
9 comments in 108-120h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 2, 2026 at 3:30 PM EST
16h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46414152Type: storyLast synced: 1/3/2026, 12:30:36 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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.
https://www.tomshardware.com/software/linux/linux-dev-swatte...
Murderous, vile, wretched Rust proponents will seek to censor, distract and downplay this.
> https://github.com/rust-lang/miri
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.