Add support for vec, slice & array in create_property_blob

[asjthilakqube]

To support vectors and slices in addition to arrays in the create_property_blob function, you can use generics and trait bounds to handle different types of data.

• The function now accepts a slice (&[T]) instead of a reference to a single object (&T).
• This allows the function to work with arrays, vectors and slices seamlessly since all of them can be converted to slices.
• The as_ptr() method is used to get a raw pointer to the slice's data.
• The length of the slice is multiplied by the size of the type T to calculate the total size in bytes

This modification ensures that the function is flexible and can handle different types of contiguous data structures.

[MarijnS95]

(Typo in the title arary -> array)

Perhaps if T was ?Sized and std::mem::size_of_val() is called, slices (with a runtime length) could still be passed, but care has to be taken to pass arbitrary objects:

fn test<T: ?Sized>(x: &T) {
    dbg!(std::mem::size_of_val(x));
    // dbg!(std::mem::size_of::<T>());
}

fn main() {
    let x = vec![1u32];
    dbg!(test(x.as_slice())); // 4, byte-size of the slice
    dbg!(test(&x)); // 24, size of the `Vec<..>` structure
}

[asjthilakqube]

Done 👍 agreed! Made the requested changes @MarijnS95

[asjthilakqube]

Hi @Drakulix, can you review this PR ?? We need this updated crate :)

[Drakulix]

LGTM. Thanks!

[MarijnS95]

Perhaps this PR should have been squashed before it was rebase-merged (or it should have been squash-merged).

Note that the function as written is still unsound, because it crates a safe &[u8] (&mut [u8] even) slice to an arbitrary &T which might contain uninitialized padding bytes. This is why bytes_of specifically requires NoUninit in bytemuck: https://docs.rs/bytemuck/latest/bytemuck/trait.NoUninit.html

[Drakulix]

Perhaps this PR should have been squashed before it was rebase-merged (or it should have been squash-merged).

Yes, that was an oversight.

Note that the function as written is still unsound, because it crates a safe &[u8] (&mut [u8] even) slice to an arbitrary &T which might contain uninitialized padding bytes. This is why bytes_of specifically requires NoUninit in bytemuck: https://docs.rs/bytemuck/latest/bytemuck/trait.NoUninit.html

Right, we should probably add the same trait requirement or directly use bytes_of given we already depend on bytemuck anyway.

[MarijnS95]

Unfortunately bytes_of requires a Sized bound. It's been a while but I remember writing some compat code around this, IIRC bytemuck doesn't have a single elegant API that accepts both a Sized T as well as a &[T] which is not Sized because it only has a size at runtime.

[MarijnS95]

And like I mentioned in #219 (comment), the title is misleading because passing a &Vec will give you the 24 pointer/capacity/size values as bytes, not the data it's pointing to - the_vec.as_slice() has to be passed to get a &[T] into this function instead.

[Drakulix]

And like I mentioned in #219 (comment), the title is misleading because passing a &Vec will give you the 24 pointer/capacity/size values as bytes, not the data it's pointing to - the_vec.as_slice() has to be passed to get a &[T] into this function instead.

I still think supporting slices is a good idea, I am not sure how to add trait bounds that would enforce a deref for Vec.

At least we should add more documentation on this issue before pushing a new release, but I am open for better ideas.

[MarijnS95]

Those bytemuck marker traits are (probably) not implemented for Vec, but as mentioned one comment prior I'm not sure if they allow passing Sized &T and unSized &[T] into a single entrypoint while working uniformly.