Canvas unsafe code in the wild

[RalfJung]

@Amanieu

This is necessary because in the case of Rc<TraitObject>, the offset of the inner value depends on the alignment of the actual object. For trait objects, the alignment is a field in the vtable, which the compiler uses to calculate the offset.

You are saying that for the same trait, the offset in Rc<Trait> can differ? Wow, I did not realize that is possible. Thanks for pointing it out!

[nikomatsakis]

@RalfJung

However, one interesting question is whether it is possible to implement memcpy in Rust by doing byte-wise copy of a [u8], or whether it will have to be a magical intrinsic.

In the compiler sprint, we felt that it would be possible, but using a union to account for the 'maybe uninitialized' nature of the data (that is, you could cast your &[u8] into a &[Uninit<u8>], where union Uninit<T> { init: T, uninit: () } (or something like that).

[briansmith]

• In ring, we sometimes need to treat a &[u64] slice as a &[u32] slice and/or a &[u8] slice. We use unsafe to do this, but we would prefer it to be built into libcore or the language instead.

• For various reasons we benefit from converting a slice &[u8] to an array reference &[u8; n] after verifying that the slice has n elements, which requires us to use unsafe. This is another thing that we think should be built-in to the language and/or standard library instead.

We keep our hacks for things that should be built-in in one module:

briansmith/ring/blob/master/src/polyfill.rs

[newpavlov]

Almost the same thing mentioned by Brian is done in the RustCrypto too. This code is stored in the separate crate called byte-tools. Essentially it’s a specialized version of byteorder without generic capabilities and with operations on slices.

I agree with Brian and think that such tools must be included in the standard library.