Skip to content

Commit

Permalink
explain place alignment
Browse files Browse the repository at this point in the history
  • Loading branch information
RalfJung committed Aug 22, 2023
1 parent f4876d6 commit 807f4d7
Showing 1 changed file with 8 additions and 1 deletion.
9 changes: 8 additions & 1 deletion src/behavior-considered-undefined.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ code.
</div>

* Data races.
* Accessing (loading from or storing to) a place that is [dangling] or unaligned.
* Accessing (loading from or storing to) a place that is [dangling] or [unaligned].
* Performing a place projection that violates the requirements of [in-bounds
pointer arithmetic][offset]. A place projection is a [field
expression][project-field], a [tuple index expression][project-tuple], or an
Expand Down Expand Up @@ -100,6 +100,13 @@ reading uninitialized memory is permitted are inside `union`s and in "padding"

The span of bytes a pointer or reference "points to" is determined by the pointer value and the size of the pointee type (using `size_of_val`).

### Unaligned places
[unaligned]: #unaligned-places

The alignment requirement of a place is computed based on the entire place expression since the last `*` (if any).
If the place was computed via `(*ptr).field.field`, then the final place is considered aligned only if `ptr` is aligned *according to its type*.
For instance, if a field of type `u8` sits at offset 4 in an 8-aligned struct, then loading from `(*ptr).field` requires alignment 4.

### Dangling pointers
[dangling]: #dangling-pointers

Expand Down

0 comments on commit 807f4d7

Please sign in to comment.