ptr::read and ptr::write (and others?) should specify alignment requirements in their contract

[whitequark]

Currently, these functions do not say anything about whether the raw pointer has to be aligned. They are also currently implemented with copy_nonoverlapping, which means they are safe to use with unaligned data. However, @ubsan tells me that this is an implementation detail that cannot be relied on.

In any case, these functions should explicitly specify their alignment requirements. Similarly, ptr::copy{,_nonoverlapping} also should do that, since right now they do not explicitly state that in their contract either. (They do reference C's memcpy and memmove, but I don't think that a C reference is a good way to define normative semantics.)

[strega-nil]

ping @Amanieu

[Amanieu]

See rust-lang/rfcs#1725

[Amanieu]

Also keep in mind that copy(_nonoverlapping) does have alignment requirements: it's based on the type of the pointer. So if you pass a *mut u32 to copy_nonoverlapping then LLVM will assume that the pointer is aligned to 4 bytes.

[whitequark]

That then should be explicitly specified also, because it is definitely not a part of the C memcpy semantics.

[bluss]

Maybe it's obvious in this discussion, but *ptr (copy to value from raw pointer) requires ptr to be aligned, of course. With that as the baseline, I think it would have to be assumed that read/write use that rule if nothing else is documented -- but why not document it explicitly.

[strega-nil]

@bluss That's also never documented, to be clear, except in the not-right-places in the nomicon.

[tbu-]

Seems to be fixed, the documentation says:

The pointer must be aligned; use write_unaligned if that is not the case.

and similarly for ptr::read.

[strega-nil]

Recommend closing as fixed.

[whitequark]

copy{,_nonoverlapping} don't have mention of alignment in the documentation still.

[arielb1]

@whitequark

That's because it has none.

[whitequark]

Also keep in mind that copy(_nonoverlapping) does have alignment requirements: it's based on the type of the pointer. So if you pass a *mut u32 to copy_nonoverlapping then LLVM will assume that the pointer is aligned to 4 bytes.

@Amanieu above disagrees...

[tbu-]

The linked RFC (by @Amanieu) states that it uses copy_nonoverlapping for {read,write}_unaligned.

[arielb1]

@whitequark

I had the mistaken impression that copy_nonoverlapping took a u8 parameter.

[Mark-Simulacrum]

Okay, so this appears to be a documentation issue -- we need to update ptr::copy{,_nonoverlapping} to state something about alignment.

[QuietMisdreavus]

The docs team discussed this today. Here's the current state of the ptr module, with respect to alignment:

<ubsan> because anything in the standard library which takes a raw pointer assumes validity of the
        raw pointer, unless it's explicitly denoted `_unaligned`, in which case size must be valid,
        but alignment might not be
(...)
<ubsan> copy{_nonoverlapping}, read_volatile, probably replace, probably swap (uses "valid",
        probably could be more wordy), write_volatile, swap_nonoverlapping
<ubsan> we should also standardize this documentation across all of the functions
(...)
<ubsan> (some put their requirements under "Safety", some put it under "Undefined Behavior", etc.)

Basically, to really close this issue it would be prudent to go over every function in ptr and leave a note about the assumed alignment requirements of it.

Since #29371 is still open, i'm considering this issue part of that one.

[ecstatic-morse]

@steveklabnik. This was completed in #53783. All functions in std::ptr now state their alignment requirements in the "Safety" section.

[steveklabnik]

Thank you!