-
Notifications
You must be signed in to change notification settings - Fork 312
clarify what is UB #149
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.
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
clarify what is UB #149
Changes from 7 commits
dfb93b2
1dcafde
280761a
86d9e2c
3241c00
909b14c
f59eca2
738a338
0f51082
efb5086
df5ff63
c41d492
1f613d8
c73730b
bd6215e
7386b5c
864625f
64bf0a5
86a89ae
c5778a1
7703c18
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,19 +16,32 @@ to your program. You definitely *should not* invoke Undefined Behavior. | |
| Unlike C, Undefined Behavior is pretty limited in scope in Rust. All the core | ||
| language cares about is preventing the following things: | ||
|
|
||
| * Dereferencing null, dangling, or unaligned pointers | ||
| * Loading from or storing to null, dangling, or unaligned references or raw | ||
| pointers | ||
| * Performing out-of-bounds arithmetic for the computation of an | ||
| `enum`/`struct`/array/slice/tuple field address | ||
| * Reading [uninitialized memory][] | ||
| * Breaking the [pointer aliasing rules][] | ||
| * Producing invalid primitive values: | ||
| * dangling/null references | ||
| * Producing invalid primitive values (either alone or as a field of a compound | ||
RalfJung marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| type such as `enum`/`struct`/array/tuple): | ||
|
||
| * dangling/null/unaligned references | ||
| * null `fn` pointers | ||
| * a `bool` that isn't 0 or 1 | ||
| * an undefined `enum` discriminant | ||
RalfJung marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| * a `char` outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF] | ||
| * A non-utf8 `str` | ||
| * a non-utf8 `str` | ||
|
||
| * an invalid library type with custom invalid values, such as a `NonNull` or | ||
| `NonZero*` that is 0 | ||
RalfJung marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| * Unwinding into another language | ||
| * Causing a [data race][race] | ||
RalfJung marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| "Producing" a value happens any time a value is assigned, passed to a | ||
| function/primitive operation or returned from a function/primitive operation. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggested reword and massive clarification: Many have trouble accepting the consequences of invalid values, so they merit some extra discussion. The claim being made here is a very strong one, so read carefully. A value is produced whenever it is assigned, passed to something, or returned from something. Keep in mind references get to assume their referents are valid, so you can't even create a reference to an invalid value. Additionally, uninitialized memory is always invalid, so you can't assign it to anything, pass it to anything, return it from anything, or take a reference to it. (Padding bytes are not technically part of a value's memory, and so may be left uninitialized.) In simple and blunt terms: you cannot ever even suggest the existence of an invalid value. No, it's not ok if you "don't use" or "don't read" the value. Invalid values are instant Undefined Behaviour. The only correct way to manipulate memory that could be invalid is with raw pointers using methods like
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I applied most of your suggestions but this one is big enough that it is probably easier to hand the PR off to you. ;) I'd love to do a pass over what you got when you are done, if you don't mind. I like this new text, as usual in you very pointed style! One comment though:
That's not true for |
||
|
|
||
| A reference/pointer is "dangling" if not all of the bytes it points to are part | ||
| of the same allocation. The span of bytes it points to is determined by the | ||
| pointer value and the size of the pointee type. | ||
|
|
||
| That's it. That's all the causes of Undefined Behavior baked into Rust. Of | ||
| course, unsafe functions and traits are free to declare arbitrary other | ||
| constraints that a program must maintain to avoid Undefined Behavior. For | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.