`Box<[T]>::into_raw` is useless

[vinipsmaker]

Sorry about the horrible title, but I really don't know how to else "summarize" this problem.

I tried to get an answer for this several times on StackOverflow (after documentation proved useless) and now I'm coming here. Maybe it's just a matter of updating documentation to have guarantees of a behaviour that will continue to work on future versions of Rust (the main purpose of documentation in the first place) or maybe the error is me who failed to spot the useful part.

I need to expose a Rust library to C applications and I need to expose an array of size only know at runtime to a function which will own this data and later will call a Rust function to deallocate it. I have a Vec<u8> and I need to get this (*mut u8, usize) tuple out of it. Later I need to get receive this same tuple and deallocate its data.

One option is to use mem::forget + Vec::from_raw_parts, but this is far from ideal as shrink_to_fit isn't guaranteed to work and I'd also need to store capacity (the C library really shouldn't need to worry about that).

The perfect option would be to use Vec::into_boxed_slice. However, it crashed when I tried to use the pointer for the first element (slice::as_mut_ptr) to Box::from_raw, as it should. And I cannot pass the pointer return from Box::into_raw to the C function, as the memory layout is unspecified and I don't have any guarantee it'll be a pointer to the first element.

How do we fix this? Update documentation? Add some extra function to Box<[T]> like Box<[T]>::from_raw_parts(ptr: *mut T, len: usize)?

[nagisa]

I have a Vec and I need to get this (*mut u8, usize) tuple out of it. Later I need to get receive this same tuple and deallocate its data.

vec.shrink_to_fit();
let ptr = vec.as_mut_ptr();
let len = vec.len();
::std::mem::forget(vec);
// <snip>
drop(Vec::from_raw_parts(ptr, len, len));

this is far from ideal as shrink_to_fit isn't guaranteed to work… The perfect option would be to use Vec::into_boxed_slice. However, it crashed when I tried to use the pointer for the first element (slice::as_mut_ptr) to Box::from_raw,

This is how you construct a fat slice box out of pointer and capacity:

let slice = slice::from_raw_parts_mut(ptr, capacity);
let boxed_slice: Box<[T]> = Box::from_raw(slice);

shrink_to_fit is exactly what Vec::into_boxed_slice does before making a boxed slice, so there’s really absolutely no difference between using that or Vec::into_boxed_slice.

And I cannot pass the pointer return from Box::into_raw to the C function, as the memory layout is unspecified and I don't have any guarantee it'll be a pointer to the first element.

You should be able to pass [T]::as_mut_ptr() to C code just fine.

[ollie27]

@nagisa shrink_to_fit doesn't guarantee that the length will equal the capacity so I think into_boxed_slice is the correct thing to use.

[nagisa]

@ollie27 then we have a larger problem of invalid implementation of Vec::into_boxed_slice.

[ollie27]

See #29847.

[ustulation]

I think the problem is with documentation. shrink_to_fit from the documentation isn't guaranteed to make capacity == len. So if you loose information about capacity, from_raw_parts is an undefined behaviour (if you assume len == capacity and pass it as such). I assume the only way into_vec() on Boxed-slice will be well behaved is if it guarantees to make len == capacity but documentation says it's exactly as if we did shrink_to_fit. This seems contradictory.

[vinipsmaker]

I think boxed slice is more appropriate here. We don't need to give more guarantees to Vec. We could just "fix" boxed slice.

[vinipsmaker]

Hey guys, any update on this? Our FFI interfaces still feel weird taking a capacity member everywhere.