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.