Canvas unsafe code in the wild


#21

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!


#22

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).


split this topic #23

30 posts were split to a new topic: Role of UB / uninitialized memory


Role of UB / uninitialized memory
Role of UB / uninitialized memory
#34
  • 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:


Role of UB / uninitialized memory
Role of UB / uninitialized memory
#35

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.