What to do with transmute_copy

[strega-nil]

This function is a terror. It is full of undefined behavior, even more than it's sister, transmute. The only uses of this function are either Undefined Behavior, are transmutes, except that they didn't try, or are just transmutes in a generic context.

This is unfortunate. I think we should make this function either much more useful, or deprecate it and get rid of the undefined behavior.

Changing the definition to:

unsafe fn transmute_copy<T: ?Sized, U>(t: &T) -> U { 
    let u: U = std::mem::uninitialized();
    std::ptr::copy_nonoverlapping(t as *const t as *const u8, &mut u as *mut u as *mut u8
                                  std::mem::size_of::<U>());
    u
}

would allow us to pull types from byte arrays, for example, without having to do this all by hand.

Otherwise, it should be deprecated, because it isn't really useful enough, and leads to far too many issues; it's only stable because transmute was unstable at the time.

[Amanieu]

Why can't we just add ?Sized to the existing definition? The change you are proposing is to effectively remove the requirement that the address of t is suitably aligned for reading a U. If your intent is to support unaligned reads and writes then I think we would be better off adding specialized ptr::read_unaligned and ptr::write_unaligned functions rather than messing with the definition of transmute_copy.

Regarding your point that transmute_copy isn't useful, I have to disagree. I make extensive use of it in atomic-rs since it is used in a generic context, which makes plain transmute unusable.

[strega-nil]

@Amanieu That is my first suggestion. Change the definition to <T: ?Sized...

If it is used in the community extensively, I'd like that we change it to <T: ?Sized, U>. I don't like that transmute allows unaligned reads, while transmute_copy does not. It's unexpected, and leads to undefined behavior.

[strega-nil]

I'd argue you should use ptr::{read, write} if you need the unsafe, assumes aligned behavior.

[arielb1]

transmute allows unaligned reads

transmute takes a copy (or move) of its source. Any alignment issues occur outside of it.

I'm however +1 for transmute_copy using copy_nonoverlapping rather than ptr::read.

[Amanieu]

I would rather avoid having transmute_copy abused for unaligned access since that is not its main purpose. We should instead add ptr::read_unaligned and ptr::write_unaligned specifically to support unaligned access.

I think changing the signature of transmute_copy to allow ?Sized for the source is pretty uncontroversial.

The main issue that needs to be discussed is what the alignment requirements for the source argument of transmute_copy should be. I see 3 options:

• Must be suitably aligned for the source type
• No alignment requirement (what @ubsan is proposing)
• Must be suitably aligned for the target type (what is currently implemented)

[strega-nil]

@Amanieu ptr::copy_nonoverlapping is a fine way to do unaligned access. It's what ptr::{read,write}_unaligned would desugar to.

[RalfJung]

I don't know why this issue got closed in 2017 (@ubsan do you remember?), but 1.5 years later with rust-lang/rust#55052 the implementation got changed to use read_unaligned.

[strega-nil]

@RalfJung I believe this was closed when I left the Rust community, and didn't want to deal with it.

[RalfJung]

Then I guess I can just hope that there's nothing else we lost track of because of issues being closed like that...