Skip to content
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

to_bitvec and related functions returning invalid values #228

Open
XAMPPRocky opened this issue May 29, 2023 · 2 comments
Open

to_bitvec and related functions returning invalid values #228

XAMPPRocky opened this issue May 29, 2023 · 2 comments

Comments

@XAMPPRocky
Copy link

Hello, if you run the below code you can see that while these should return the same value, the second instance returns [0x7, 0x80].

use bitvec::prelude::*;
assert_eq!(bitvec::bits![u8, Msb0;       0, 0, 0, 1, 1, 1, 0, 1].to_bitvec().into_vec(), vec![29]);
assert_eq!(bitvec::bits![u8, Msb0; 1, 1, 0, 0, 0, 1, 1, 1, 0, 1][2..].to_bitvec().into_vec(), vec![29]);
@Trolldemorted
Copy link

Is this an endianess problem?

let data: Vec<u8> = vec![0b0000_0000, 0b1111_1111];
let slice = data.view_bits::<Msb0>();
info!("{:04b}", slice[6..10].load::<u64>());

is printing 1100 instead of 0011.

I work around this with a loop (read until word boundary, shift subslice to the left, continue), but that means I have to do sign extension manually.

Bug or a feature?

@Trolldemorted
Copy link

Ran your numbers, in your case it does not look like an endianess problem, and rather like a generic "reads across word boundaries" problem. I guess what happens is

  • bitvec reads from the start position until the end of the first word (00_0111)
    • this value is zeroextended to 0000_0111 (aka 0x7) and appended to the output
  • bitvec reads the remaining bits from the second word (01)
    • this value is shifted by 6 to 0100_0000 (aka 0x80), because the bitvec ended 6 bits before the end of the current word, and the result is appended to the output

@myrrlyn could you clarify what the expected output is? I guess there must be tests covering reads across word boundaries, therefore this behaviour might be intended (?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants