-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix BitVec on Big-Endian Systems #43
Comments
Awesome. I've always been afraid these were subtly incorrect and I just didn't have a machine on which to test them. |
Some further debugging with a lot of printlns shows that it's store_le that's failing: println!("0x1234u16.to_le_bytes()={:?}", 0x1234u16.to_le_bytes());
// 0x1234u16.to_le_bytes()=[52, 18]
let u16b = u16::from_ne_bytes(0x1234u16.to_le_bytes());
println!("u16b={:?}", u16b);
// u16b=13330
bytes[..16].store_le(u16b);
println!("bytes[..16]={:?}", bytes[..16]);
// ACTUAL: bytes[..16]=BitSlice<Lsb0, u8> [01001000, 00101100]
// EXPECTED: bytes[..16]=BitSlice<Lsb0, u8> [00101100, 01001000] Now, I"m not sure if this is a real issue, or faulty assumptions during unittesting, since |
The more I look at this, the more I believe this is simply a logic bug in the testing suite. The following works, as expected: let u16b = u16::from_ne_bytes(0x1234u16.to_ne_bytes());
bytes[..16].store_le(u16b);
assert_eq!(bytes[..16].load_le::<u16>(), 0x1234u16); |
On big-endian, one more issue: let bits: &BitSlice<Local, usize> = bits![1, 0, 1, 1, 0, 1, 0, 0, 1, 0];
println!("bits={:?}", bits);
// bits=BitSlice<Msb0, usize> [0000000000] The bits macro is therefore broken on big-endian architectures. |
In my case (little-endian) bitvec! makes wrong initialization after 48th bit. let bits = bitvec![0, 1, 0, 1, 1, 0, 1, 1, 0, 0,
0, 0, 0, 0, 0, 0, 1, 1, 0, 0,
0, 0, 0, 0, 0, 0, 1, 1, 0, 0,
0, 1, 0, 1, 1, 0, 1, 1, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
println!("{:?}", bits);
// BitVec<Lsb0, usize> [
// 0b0101101100000000110000000011000101011011000000001100000000110001,
// 0b000000,
//] |
Thank you @obeah for this issue report. The behavior is now fixed on trunk. I will cherry-pick it down into a |
The byte-reärranging functions in `macros/internals.rs` had copy-paste errors in the `u64` variants. (cherry picked from commit af5ee02)
Relevant Code Failing
Result
On big-endian PPC, the above code cails, but on little-endian PPC, it passes.
The text was updated successfully, but these errors were encountered: