Skip to content

Update definition of UB in the glossary #203

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

Closed
wants to merge 9 commits into from
Closed

Update definition of UB in the glossary #203

Changes from 7 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
e6a7306
Update definition of UB in the glossary
gnzlbg Sep 11, 2019
79b503d
Reword
gnzlbg Sep 12, 2019
447871d
Reword
gnzlbg Sep 12, 2019
9d1edd1
Reword
gnzlbg Sep 12, 2019
dcadfa9
Reword
gnzlbg Sep 12, 2019
a8da356
Reword
gnzlbg Sep 12, 2019
cb6528c
Update reference/src/glossary.md
gnzlbg Sep 12, 2019
a952d79
Reword safe Rust requirements
gnzlbg Sep 12, 2019
7c22e1c
Merge ralf and rkruppe suggestions
gnzlbg Oct 17, 2019
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
26 changes: 16 additions & 10 deletions reference/src/glossary.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,16 +149,22 @@ For some more information, see [this blog post](https://www.ralfj.de/blog/2018/0
#### Undefined Behavior
[ub]: #undefined-behavior

*Undefined Behavior* is a concept of the contract between the Rust programmer and the compiler:
The programmer promises that the code exhibits no undefined behavior.
In return, the compiler promises to compile the code in a way that the final program does on the real hardware what the source program does according to the Rust Abstract Machine.
If it turns out the program *does* have undefined behavior, the contract is void, and the program produced by the compiler is essentially garbage (in particular, it is not bound by any specification; the program does not even have to be well-formed executable code).

In Rust, the [Nomicon](https://doc.rust-lang.org/nomicon/what-unsafe-does.html) and the [Reference](https://doc.rust-lang.org/reference/behavior-considered-undefined.html) both have a list of behavior that the language considers undefined.
Rust promises that safe code cannot cause Undefined Behavior---the compiler and authors of unsafe code takes the burden of this contract on themselves.
For unsafe code, however, the burden is still on the programmer.

Also see: [Soundness][soundness].
*Undefined Behavior* (UB) is the behavior for which the Rust language provides no guarantees. Rust programs that do **not** exhibit *undefined behavior* execute according to the semantics of the Rust Abstract Machine on real hardware.
Rust imposes no requirements on programs that exhibit undefined behavior; these programs are not bound by any specification.
Rust promises that *safe* Rust is [sound][soundness], that is, that it does not exhibit *undefined behavior*. `unsafe` Rust code that allows *safe* Rust code to exhibit *undefined behavior* is [unsound][soundness].

A list of behavior considered undefined is available in the [Rust Language Reference](https://doc.rust-lang.org/reference/behavior-considered-undefined.html).
Copy link
Member

Choose a reason for hiding this comment

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

Please keep the Nomicon link, I think it is useful to read this in both styles.

As long as both lists exist, I think we should link them both here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently the Nomicon link is way outdated. I'll keep both links, but maybe the nomicon should be updated to just refer to the language reference at some point.

Copy link
Member

Choose a reason for hiding this comment

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

I just (over the last few weeks) updated both of them, and the lists should actually be in sync. Why do you say it is outdated?

maybe the nomicon should be updated to just refer to the language reference at some point.

Agreed, but for now this is the situation we got.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just (over the last few weeks) updated both of them, and the lists should actually be in sync. Why do you say it is outdated?

I didn't realize that the nomicon PR was already merged.


> **Note:** In practice, UB is a contract between the Rust source code and the implementation.
Copy link
Member

Choose a reason for hiding this comment

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

The implementation of what? I think this is your C++ standard mode showing. ;)

I find "compiler" much more understandable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe. Is it only the compiler ? It is also a contract with the implementation of the abstract machine (e.g. miri, the hardware, etc.).

Copy link
Member

Choose a reason for hiding this comment

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

I think so far in the UCG documents we have always talked about "the compiler"?
I agree the proper spec might have to be more careful with terminology. But we should be consistent at least. So probably best to keep saying "the compiler" and file an issue to maybe s/compiler/Rust implementation/ or so?

> If the source code does not exhibit UB, the implementation promises to compile it to a program that will do on real hardware what the source code says it should do on the Rust Abstract Machine.
> However, if the source code exhibits UB, this contract is void, and the implementation can do *anything*.
>
> When this document says that "the behavior of `X` is undefined" that should be read as "there are no guarantees about what the behavior of `X` is".
> It could fail to compile, compile but not produce an executable binary, produce an executable binary that does garbage, or even produce an executable binary that appears to do something reasonable.
> It can also do something different every time.
>
> It is backward compatible to change the specification from making no guarantees (UB) to guaranteeing something (not UB).
> That is, Rust source code is not allowed to rely on UB being UB forever.
Copy link
Member

Choose a reason for hiding this comment

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

Why is that part just a "note"?


#### Soundness (of code / of a library)
[soundness]: #soundness-of-code--of-a-library
Expand Down