Pfthb

Using the Piston image crate, I can write an image by feeding it a Vec<u8>, but my actual data is Vec<Rgb<u8>> (because that is a lot easier to deal with, and I want to grow it dynamically).

How can I convert Vec<Rgb<u8>> to Vec<u8>? Rgb<u8> is really [u8; 3]. Does this have to be an unsafe conversion?

The answer depends on whether you are fine with copying the data. If copying is not an issue for you, you can do something like this:

let img: Vec<Rgb<u8>> = ...;
let buf: Vec<u8> = img.iter().flat_map(|rgb| rgb.data.iter()).cloned().collect();

If you want to perform the conversion without copying, though, we first need to make sure that your source and destination types actually have the same memory layout. Rust makes very few guarantees about the memory layout of structs. It currently does not even guarantee that a struct with a single member has the same memory layout as the member itself.

In this particular case, the Rust memory layout is not relevant though, since Rgb is defined as

#[repr(C)]
pub struct Rgb<T: Primitive> 
 pub data: [T; 3],

The #[repr(C)] attribute specifies that the memory layout of the struct should be the same as an equivalent C struct. The C memory layout is not fully specified in the C standard, but according to the unsafe code guidelines, there are some rules that hold for "most" platforms:

• Field order is preserved.


• The first field begins at offset 0.


• Assuming the struct is not packed, each field's offset is aligned to the ABI-mandated alignment for that field's type, possibly creating unused padding bits.


• The total size of the struct is rounded up to its overall alignment.

As pointed out in the comments, the C standard theoretically allows additional padding at the end of the struct. However, the Piston image library itself makes the assumption that a slice of channel data has the same memory layout as the Rgb struct, so if you are on a platform where this assumption does not hold, all bets are off anyway (and I couldnt' find any evidence that such a platform exists).

Rust does guarantee that arrays, slices and vectors are densely packed, and that structs and arrays have an alignment equal to the maximum alignment of their elements. Together with the assumption that the layout of Rgb is as specified by the rules I quotes above, this guarantees that Rgb<u8> is indeed laid out as three consecutive bytes in memory, and that Vec<Rgb<u8>> is indeed a consecutive, densely packed buffer of RGB values, so our conversion is safe. We still need to use unsafe code to write it:

let p = img.as_mut_ptr();
let len = img.len() * mem::size_of::<Rgb<u8>>();
let cap = img.capacity() * mem::size_of::<Rgb<u8>>();
mem::forget(img);
let buf: Vec<u8> = unsafe Vec::from_raw_parts(p as *mut u8, len, cap) ;

If you want to protect against the case that there is additional padding at the end of Rgb, you can check whether size_of::<Rgb<u8>>() is indeed 3. If it is, you can use the unsafe non-copying version, otherwise you have to use the first version above.

You choose the Vec<Rgb<u8>> storage format because it's easier to deal with and you want it to grow dynamically. But as you noticed, there's no guarantee of compatibility of its storage with a Vec<u8>, and no safe conversion.

Why not take the problem the other way and build a convenient facade for a Vec<u8> ?

type Rgb = [u8; 3];

#[derive(Debug)]
struct Img(Vec<u8>);

impl Img 
 fn new() -> Img 
 Img(Vec::new())
 

 fn push(&mut self, rgb: &Rgb) 
 self.0.push(rgb[0]);
 self.0.push(rgb[1]);
 self.0.push(rgb[2]);
 

 // other convenient methods


fn main() 
 let mut img = Img::new();
 let rgb : Rgb = [1, 2, 3];
 img.push(&rgb);
 img.push(&rgb);
 println!(":?", img);