What is the right way to allocate data to pass to

Question

After discussing/learning about the correct way to call a FFI of the Windows-API from Rust, I played with it a little bit further and would like to double-check my understanding.

I have a Windows API that is called twice. In the first call, it returns the size of the buffer that it will need for its actual out parameter. Then, it is called a second time with a buffer of sufficient size. I'm currently using a Vec as a datatype for this buffer (see example below).

The code works but I'm wondering whether this is right way to do it or whether it would be better to utilize a function like alloc::heap::allocate to directly reserve some memory and then to use transmute to convert the result from the FFI back. Again, my code works but I'm trying to look a little bit behind the scenes.

extern crate advapi32;
extern crate winapi;
extern crate widestring;
use widestring::WideCString;
use std::io::Error as IOError;
use winapi::winnt;

fn main() {
    let mut lp_buffer: Vec<winnt::WCHAR> = Vec::new();
    let mut pcb_buffer: winapi::DWORD = 0;

    let rtrn_bool = unsafe {
        advapi32::GetUserNameW(lp_buffer.as_mut_ptr(),
                               &mut pcb_buffer )
    };

    if rtrn_bool == 0 {

        match IOError::last_os_error().raw_os_error() {
            Some(122) => {
                // Resizing the buffers sizes so that the data fits in after 2nd 
                lp_buffer.resize(pcb_buffer as usize, 0 as winnt::WCHAR);
            } // This error is to be expected
            Some(e) => panic!("Unknown OS error {}", e),
            None => panic!("That should not happen"),
        }
    }


    let rtrn_bool2 = unsafe {
        advapi32::GetUserNameW(lp_buffer.as_mut_ptr(), 
                               &mut pcb_buffer )
    };

    if rtrn_bool2 == 0 {
        match IOError::last_os_error().raw_os_error() {
            Some(e) => panic!("Unknown OS error {}", e),
            None => panic!("That should not happen"),
        }
    }

    let widestr: WideCString = unsafe { WideCString::from_ptr_str(lp_buffer.as_ptr()) };

    println!("The owner of the file is {:?}", widestr.to_string_lossy());
}

Dependencies:

[dependencies]
advapi32-sys = "0.2"
winapi = "0.2"
widestring = "*"

Answer 1

This is what I came up with.

pub struct FfiObject {
    pub ptr: *mut u8,
    pub size: usize,
}
impl FfiObject {
    // allocate and zero memory
    pub fn new(size: usize) -> FfiObject {
        FfiObject::_from_vec(vec![0u8; size], size)
    }
    // allocate memory without zeroing
    pub fn new_uninitialized(size: usize) -> FfiObject {
        FfiObject::_from_vec(Vec::with_capacity(size), size)
    }
    fn _from_vec(mut v: Vec<u8>, size: usize) -> FfiObject {
        assert!(size > 0);
        let ptr = v.as_mut_ptr();
        std::mem::forget(v);
        FfiObject { ptr, size }
    }
}
impl Drop for FfiObject {
    fn drop(&mut self) {
        unsafe { std::mem::drop(Vec::from_raw_parts(self.ptr, 0, self.size)) };
    }
}

The FFI object is created using a u8 vector so that the size is in bytes. This could be generalised to using an arbitrary type instead of u8 but do keep in mind Shepmaster's warning about the distinction between the number of bytes and the number of items.

Here's an example of using FfiObject:

// Ask the library for the size.
let mut size: usize = 0;
let mut success = GetObjectSize(&mut size);
if success && size > 0 {
    // allocate and zero memory for the object
    let ffi_obj = FfiObject::new(size);
    // Pass the memory to a foreign function
    success = DoSomethingWithObject(ffi_obj.ptr, &ffi_obj.size);

Answer 2

Ideally you would use std::alloc::alloc because you can then specify the desired alignment as part of the layout:

pub unsafe fn alloc(layout: Layout) -> *mut u8

The main downside is that you need to know the alignment, even when you free the allocation.

It's common practice to use a Vec as an easy allocation mechanism, but you need to be careful when using it as such.

1. Make sure that your units are correct — is the "length" parameter the number of items or the number of bytes?
2. If you dissolve the Vec into component parts, you need to
   1. track the length and the capacity. Some people use shrink_to_fit to ensure those two values are the same.
   2. Avoid crossing the streams - that memory was allocated by Rust and must be freed by Rust. Convert it back into a Vec to be dropped.

3. Beware that an empty Vec does not have a NULL pointer!:

   fn main() {
       let v: Vec<u8> = Vec::new();
       println!("{:p}", v.as_ptr());
       // => 0x1
   }
   

---

For your specific case, I might suggest using the capacity of the Vec instead of tracking the second variable yourself. You'll note that you forgot to update pcb_buffer after the first call, so I'm pretty sure that the code will always fail. It's annoying because it needs to be a mutable reference so you can't completely get away from it.

Additionally, instead of extending the Vec, you could just reserve space.

There's also no guarantee that the size required during the first call will be the same as the size required during the second call. You could do some kind of loop, but then you have to worry about an infinite loop happening.