Unsound implementation of `transmute_vec_as_bytes` in `fyrox-core` about fyrox

[shinmao]

We also considered that array_as_u8_slice and value_as_u8_slice unsound with usages of casting. The trait of Sized doesn't pose the limitation on composite types.

• Fyrox/fyrox-core/src/lib.rs

  Line 302 in 3b03ea7

  pub fn array_as_u8_slice<T: Sized>(v: &[T]) -> &'_ [u8] {

• Fyrox/fyrox-core/src/lib.rs

  Line 319 in 3b03ea7

  pub fn value_as_u8_slice<T: Sized>(v: &T) -> &'_ [u8] {

[orzogc]

IMO something like NoUninit should be added in the trait bounds.

[NathanaelG1]

Noticed this was tagged as a good first issue, I have made some changes to the function referenced by @shinmao. Instead of adding a dependency on bytemuck, I think I was able to handle the padding issue without the use of any unsafe blocks. Ran into a lot of issues trying to handle any possible value, but noticed it is only referenced three times. Out of each case the vec is either a usize or an f32. If other types need to be supported I can add support.

I have run a modified version of the FPS tutorial as well as the RPG tutorial and all the logs appear the same as running off the latest release. All tests are passing, and I added two tests to cover the transmute_vec_as_bytes.

If I am barking up the wrong tree with this approach let me know and I can follow the suggestion by @orzogc.

I have this playground showing the current function as is and its output as well as the updated function.

I linked my PR to my forked repo and it is in the history above, should I open a PR to the main fork to receive feedback? I haven't made any documentation updates as I wanted to check with everyone if this is a valid solution. Once everything looks good to people more familiar with the project I will add a documentation update to the PR.

functions downstream of transmute_vec_as_bytes:

[mrDIMAS]

@shinmao the issue should be fixed by the recent commits, could you please re-check this?

[shinmao]

Yes. It could fix the issue.