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!
Canvas unsafe code in the wild
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).
30 posts were split to a new topic: Role of UB / uninitialized memory
Role of UB / uninitialized memory
Role of UB / uninitialized memory
-
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 hasn
elements, which requires us to useunsafe
. 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
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.