Skip to content

Commit

Permalink
Merge pull request #659 from RalfJung/ub
Browse files Browse the repository at this point in the history
update UB
  • Loading branch information
Centril authored Sep 5, 2019
2 parents 090c015 + 6c9a399 commit 9fa09f3
Showing 1 changed file with 42 additions and 24 deletions.
66 changes: 42 additions & 24 deletions src/behavior-considered-undefined.md
Original file line number Diff line number Diff line change
@@ -23,44 +23,62 @@ code.
</div>

* Data races.
* Dereferencing a null or dangling raw pointer.
* Unaligned pointer reading and writing outside of [`read_unaligned`]
and [`write_unaligned`].
* Reads of [undef] \(uninitialized) memory.
* Breaking the [pointer aliasing rules] on accesses through raw pointers;
a subset of the rules used by C.
* `&mut T` and `&T` follow LLVM’s scoped [noalias] model, except if the `&T`
contains an [`UnsafeCell<U>`].
* Mutating non-mutable data &mdash; that is, data reached through a shared
reference or data owned by a `let` binding), unless that data is contained
within an [`UnsafeCell<U>`].
* Invoking undefined behavior via compiler intrinsics:
* Indexing outside of the bounds of an object with [`offset`] with
the exception of one byte past the end of the object.
* Using [`std::ptr::copy_nonoverlapping_memory`], a.k.a. the `memcpy32`and
`memcpy64` intrinsics, on overlapping buffers.
* Invalid values in primitive types, even in private fields and locals:
* Dangling or null references and boxes.
* Dereferencing (using the `*` operator on) a dangling or unaligned raw pointer.
* Breaking the [pointer aliasing rules]. `&mut T` and `&T` follow LLVM’s scoped
[noalias] model, except if the `&T` contains an [`UnsafeCell<U>`].
* Mutating immutable data. All data inside a [`const`] item is immutable. Moreover, all
data reached through a shared reference or data owned by an immutable binding
is immutable, unless that data is contained within an [`UnsafeCell<U>`].
* Invoking undefined behavior via compiler intrinsics.
* Executing code compiled with platform features that the current platform
does not support (see [`target_feature`]).
* Calling a function with the wrong call ABI or wrong unwind ABI.
* Producing an invalid value, even in private fields and locals. "Producing" a
value happens any time a value is assigned to or read from a place, passed to
a function/primitive operation or returned from a function/primitive
operation.
The following values are invalid (at their respective type):
* A value other than `false` (`0`) or `true` (`1`) in a `bool`.
* A discriminant in an `enum` not included in the type definition.
* A null `fn` pointer.
* A value in a `char` which is a surrogate or above `char::MAX`.
* A `!` (all values are invalid for this type).
* An integer (`i*`/`u*`), floating point value (`f*`), or raw pointer obtained
from [uninitialized memory][undef].
* A reference or `Box<T>` that is dangling, unaligned, or points to an invalid value.
* Invalid metadata in a wide reference, `Box<T>`, or raw pointer:
* `dyn Trait` metadata is invalid if it is not a pointer to a vtable for
`Trait` that matches the actual dynamic trait the pointer or reference points to.
* Slice metadata is invalid if if the length is not a valid `usize`
(i.e., it must not be read from uninitialized memory).
* Non-UTF-8 byte sequences in a `str`.
* Executing code compiled with platform features that the current platform
does not support (see [`target_feature`]).
* Invalid values for a type with a custom definition of invalid values.
In the standard library, this affects [`NonNull<T>`] and [`NonZero*`].

> **Note**: `rustc` achieves this with the unstable
> `rustc_layout_scalar_valid_range_*` attributes.
A reference/pointer is "dangling" if it is null or not all of the bytes it
points to are part of the same allocation (so in particular they all have to be
part of *some* allocation). The span of bytes it points to is determined by the
pointer value and the size of the pointee type. As a consequence, if the span is
empty, "dangling" is the same as "non-null". Note that slices point to their
entire range, so it is important that the length metadata is never too
large. In particular, allocations and therefore slices cannot be bigger than
`isize::MAX` bytes.

> **Note**: Undefined behavior affects the entire program. For example, calling
> a function in C that exhibits undefined behavior of C means your entire
> program contains undefined behaviour that can also affect the Rust code. And
> vice versa, undefined behavior in Rust can cause adverse affects on code
> executed by any FFI calls to other languages.
[`const`]: items/constant-items.html
[noalias]: http://llvm.org/docs/LangRef.html#noalias
[pointer aliasing rules]: http://llvm.org/docs/LangRef.html#pointer-aliasing-rules
[undef]: http://llvm.org/docs/LangRef.html#undefined-values
[`offset`]: ../std/primitive.pointer.html#method.offset
[`std::ptr::copy_nonoverlapping_memory`]: ../std/ptr/fn.copy_nonoverlapping.html
[`target_feature`]: attributes/codegen.md#the-target_feature-attribute
[`UnsafeCell<U>`]: ../std/cell/struct.UnsafeCell.html
[`read_unaligned`]: ../std/ptr/fn.read_unaligned.html
[`write_unaligned`]: ../std/ptr/fn.write_unaligned.html
[Rustonomicon]: ../nomicon/index.html
[`NonNull<T>`]: ../core/ptr/struct.NonNull.html
[`NonZero*`]: ../core/num/index.html

0 comments on commit 9fa09f3

Please sign in to comment.