Skip to content

UB does not time travel #2320

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
RalfJung wants to merge 1 commit into
base: master
Choose a base branch
from
+4 −0
Open

UB does not time travel #2320

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions src/behavior-considered-undefined.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,10 @@ r[undefined]
r[undefined.intro]
Rust code is incorrect if it exhibits any of the behaviors in the following list. This includes code within `unsafe` blocks and `unsafe` functions. `unsafe` only means that avoiding undefined behavior is on the programmer; it does not change anything about the fact that Rust programs must never cause undefined behavior.

r[undefined.behavior]
When a Rust program encounters undefined behavior, the program may perform arbitrary operations, including but not limited to jumping to arbitrary other code (even dead code) elsewhere in the program, performing arbitrary syscalls, or jumping into memory that does not hold valid machine code.
However, undefined behavior does not "time travel": if an observable operation (I/O or a volatile accesses) occurs before the point in the source code where undefined behavior was triggered, that observable operation is guaranteed to be executed before the program encounters undefined behavior.

@traviscross traviscross Aug 7, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably we mean to define this in terms of execution order (as the C folks did) rather than source code order. E.g.:

for i in 0..10 {
    unsafe { maybe_ub(i) }; // UB only when `i == 5`.
    println!("{i}"); // After the UB point in the source code.
}

View changes since the review

@RalfJung RalfJung Aug 7, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that is what I meant. I concur that "source code order" is a bad term, but "execution order" begs the question -- which execution? The one in the Abstract Machine or the one on the Concrete Machine? Not all things happen in the same order in both.

In the memory model this is often called "program order", not sure if that is more clear. C++ calls it "sequenced-before".


r[undefined.soundness]
It is the programmer's responsibility when writing `unsafe` code to ensure that any safe code interacting with the `unsafe` code cannot trigger these behaviors. `unsafe` code that satisfies this property for any safe client is called *sound*; if `unsafe` code can be misused by safe code to exhibit undefined behavior, it is *unsound*.

Expand Down
Loading