cast_slice fails &[u8] -> &[f32] about bytemuck HOT 5 CLOSED

Sooo I understand this is completly what the TargetAlignmentGreaterAndInputNotAligned error is saying ... sorry for the noise

from bytemuck.

Ok, it seems unrelated to glam:

fn main() {
    // will not panic with this line uncommented
    // dbg!(bytemuck::cast_slice::<f32, u8>(&[0.0; 4]));
    dbg!(bytemuck::cast_slice::<u8, f32>(&[0u8; 16]));
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1d70b67efac2e1cdb98d8a5bcd8ef86d

from bytemuck.

Things are getting more and more weird ...
patching the reproduction repository make it works under some conditions:

[patch.crates-io]
# With local bytemuck, it works (it's really just the main branch cloned)
#bytemuck = { path = "../bytemuck" }
# pulling from github make it fail again ...
bytemuck = { git = "https://github.com/Lokathor/bytemuck.git", branch = "main" }

from bytemuck.

Keeping the investigation...

this line : https://github.com/Lokathor/bytemuck/blob/main/src/lib.rs#L430
assumes the u8 slice start memory address will be aligned to a f32 representation, which might no be the case ... declaring an f32 right before the slice declaration forces the memory addess to be a multiple of 4

let arr: &[f32] = &[0.0]; // try comment or uncomment this line
let bytes: &[u8] = &[0u8; 16];
dbg!(bytes.as_ptr() as usize % align_of::<f32>());

from bytemuck.

To be more precise... this seems to always produce the wrong result

let f: &f32 = &0.0; // stack memory address aligned to %4
let u: &u8 = &0u8; // %4 + 1
let bytes: &[u8] = &[0u8; 16]; // off from f32 alignment
dbg!(bytes.as_ptr() as usize % align_of::<f32>()); // outputs 1 where bytemuck expect 0

from bytemuck.