2

I am experimenting with an API where the callers provide a Vec<Point> which they want me to fill in with data. They can allocate room in the vector by creating it with with_capacity then push out its size by doing push(Point{...}). Then I will fill the underlying buffer with bytes from the disk, switch their endian representation as necessary, and then provide it back as a Vec<Point>.

Here is the function which takes their vector and fills it with data. The problem is that transmute only works when the types are of the same size, a Point is 12 bytes and transmute throws away 11 of those bytes.

fn read_points(&self, offset: u64, points: &mut [point::Point]) {
    let mut file = self.handle.borrow_mut();
    file.seek(SeekFrom::Start(offset)).unwrap();

    // bleep bloorp. danger!
    let points_buf : &mut [u8] = unsafe { mem::transmute(points) };
    file.read(points_buf).unwrap();

    // should take the 12 bytes and do the endian swaps
    for mut chunk in points_buf.chunks_mut(point::POINT_SIZE) {
        let point = point::buf_to_point(chunk);
        let buf : &mut [u8] = &mut chunk;
        point::fill_buf(buf, point.timestamp, point.value);
    }
}

Can this API be done in Rust or should I should I switch to doing safer but slower copy operations?

xrl
  • 2,155
  • 5
  • 26
  • 40
  • Perhaps you want something like http://stackoverflow.com/q/28127165/155423 ? – Shepmaster Jun 09 '15 at 18:02
  • 1
    Not quite, I don't want to change memory representation and bincode does not appear to give the in-place swap I want. I want to control how the values are read for endianness by borrowing a Vec as a Vec (same total size for both), I want to do in place manipulation of the Vec in chunks and then go back to use the data as a Vec. I need access to the underlying slice as if it were &[u8] temporarily to manipulate byte orders. – xrl Jun 09 '15 at 19:01
  • I don't know the answer, but I wonder how you could be sure that there aren't padding issues - like if a 15-byte struct was actually padded to 16 bytes for storage reasons; every 16 bytes would be a piece of undefined memory... – Shepmaster Jun 09 '15 at 19:12
  • Right, that's a good point. I think alignment will be OK and I'm pretty sure that the vector's backing array will store the values aligned one directly after the other. Also, I may need to force the representation of the struct to be `#[repr(C)]` so the struct is close packed. – xrl Jun 09 '15 at 20:40

1 Answers1

4

The memory representation of &mut [T] is (*mut T, usize) where usize is the number of T elements in the slice, not the number of bytes. So transmuting a slice of say 20 points gives you a slice of 20 bytes.

You have to compute the correct number of bytes:

let n_bytes = points.len() * std::mem::size_of::<Point>();
let points_buf = std::slice::from_raw_parts_mut(points.as_mut_ptr(), n_bytes);

(Then of course deal of all the rest of the unsafety.)

Simon Sapin
  • 9,790
  • 3
  • 35
  • 44