Unsound assumption about the alignment of u32 and f32

[anforowicz]

An unsafe transmute between &[f32] and &[u32] is performed here:

byteorder/src/lib.rs

Lines 1202 to 1208 in 8d9f0c0

	#[inline]
	fn read_f32_into(src: &[u8], dst: &mut [f32]) {
	let dst = unsafe {
	slice::from_raw_parts_mut(dst.as_mut_ptr() as *mut u32, dst.len())
	};
	Self::read_u32_into(src, dst);
	}

.

The transmute may lead to Undefined Behavior if &[u32] has stricter alignment requirements than &[f32]. Primitive types (e.g. u32 or f32) are usually aligned to their size, but this is a platform specific behavior. A platform could in theory define f32 to be aligned on a 2 byte boundary, while saying that u32 must be aligned on 4 bytes. That would make read_u32_into an unaligned write.

One way to avoid the unsound assumptions is to enforce them at compile time as follows:

const _CHECK_ALIGN: () = assert!(align_of::<u32>() <= align_of::<f32>());

Many thanks to @kupiakos for finding this issue and suggesting the compile-time assertion above.