auxoncorp/fixed-slice-vec

Vec with dynamic length and runtime-determined capacity backed by a slice. no_std , no-allocator friendly.

fixed-slice-vec's Issues

Mark constructors which accept `&mut [u8]` as unsafe

As noted by @HeroicKatora , these constructors mean that when a user writes a type with padding bytes into the backing slice, and then the FixedSliceVec/single is released, those padding byte contents are visible in the original backing collection, which is undefined behavior.

At very least this deserves requiring users to opt-in to managing the appropriate safety concerns.

Few suggestions

I just encountered use-case where your crate can be suitable but noticed few things that should be improved.

Correctness suggestions

Drop probably shouldn't be implemented if elements is not drop

Code here
https://github.com/auxoncorp/fixed-slice-vec/blob/df78d1635a8694e9aad95d275daf53ed394e4a49/src/vec.rs#L22..L26

I suggest to add additional bound T: Drop here because it would be noop anyway after optimization.
With new bound, rustc wouldn't generate drop calls when FixedSliceVec with Copy types goes out of scope so it would have less compilation errors.

Also, it would make programs like that compile (currently you need to manually drop v before second loop):

let mut arr: [MaybeUninit<u32>; 50] = MaybeUninit::uninit_array::<50>();
let mut v: FixedSliceVec<u32> = (&mut arr[..]).into();
for i in 0..10{
   v.push(i);
}

for v in arr[..10].iter(){}

FixedSliceVec::clear and FixedSliceVec::truncate can double drop

Code here

fixed-slice-vec/src/vec.rs

Line 291 in df78d16

pub fn clear(&mut self) {

If vec contains few items inside and item in the middle panics during dropping, you can call clear again and make double-free for first items in vec.
I suggest to move length zeroing before unsafe block so you would just leak data in case of panic.

Another option is to call pop until our len is 0 but it can be less performant and would make API not clear (e.g. we can still have items after panic).

Same can happen in truncate function.

FixedSliceVec::pop can be improved

Code here
https://github.com/auxoncorp/fixed-slice-vec/blob/df78d1635a8694e9aad95d275daf53ed394e4a49/src/vec.rs#L281..L282

It would be easier for optimizer to understand code like that:

self.len -= 1;
/*return*/ Some(unsafe { self.storage[self.len].as_mut_ptr().read() } )

It uses MaybeUninit utilities instead of slice trick.

My own use-case suggestion

It would be useful to be able convert vec to initialized part of inner slice if elements is Copy. Since elements is Copy they cannot implement Drop so we don't need to worry about leaking elements.

Use case:

/// Returns all items which was processed.
fn do_some_processing_for_items<'a>(items: &[u32], buffer_for_output: FixedSliceVec<'a>)->&'a [u32]{
     for item in items.iter(){
         if can_process(item){
            process_item(item);
            buffer_for_output.push(*item);
         }
     }
     buffer_for_output.into_initialized_slice()
}

Expand empirical testing

This crate needs dramatically more tests and a greater variety of tests.

• Property based testing (via proptest , most likely)
• Fuzz testing ( AFL or fuzzcheck)
• miri testing

Unsound From<&'a mut [T]> implementation

As mentioned on reddit:

1. Create an array of 3 String.
2. Initialize a FixedSliceVec<'_, String> with it.
3. Call clear, all 3 String are dropped.
4. At the end of the function, the array is dropped, dropping the String again.

with_capacity_align_from_uninit_bytes

I would say it would be incredibly useful to have such alignment function in cases where multiple vectors are to be allocated.

For instance, here, in our memflow project, we perform a series of slice splits to allocate the buffers, with intention of allocating that particular number of elements in each, rather than "just how many fit in the misaligned buf". This is particularly troublesome here, where the allocated buffer is expected to fit exactly that many elements. However, in some cases the split slice is misaligned, and the resulting capacity is zero (thus I had to add extra bytes in the split).

A with_capacity_align_from_uninit_bytes function (a really long name, would probably need something simpler) would try to align and split the slice to house just that particular amount of elements, while keeping the end to be freely used by other vecs.

If you think this is an useful feature, I could go ahead, add it in, and create a PR.

Alignment with arrayvec

I'm curious what you found that prevents the arrayvec crate itself from being modified to support both array and slices? I suppose the compiler might fail to propagate the constant length somewhere, causing a performance regression relative to arrayvec?