Possibly broken big int serialization with bit positions

[janbraiins]

Hello,

I have added a test case that demonstrates an issue with serialization of structure that is longer than 1 byte (4 in this case), however uses bit-oriented mapping. Could you confirm that this is a bug?

The test case is in a separate branch:

https://github.com/braiins/packed_struct.rs/tree/broken-big-ints

Thanks Jan

[rudib]

No, I don't believe that there is an issue with the library, however, you might have confused the LSB0 and MSB0 bit positionings. In these cases, try to use the generated Display trait of a packed structure which might help you with understanding the packing layout. First, here is the packing layout for your original bug report:

BigIntsLsb (4 bytes)

Decimal
[239, 190, 0, 71]

Hex
[0xEF, 0xBE, 0x0, 0x47]

Binary
[0b11101111, 0b10111110, 0b00000000, 0b01000111]

 val1 | bits  29:31  | 0b111              | "7"
 val2 | bits  25:25  | 0b1                | "true"
 val3 | bits   0:15  | 0b1110111110111110 | "48879"

To print out this layout, just use println!("{}", a);. Note that this layout display always uses MSB0 bit positioning, the same as the library does internally. This might need to be altered so that it is more explicit.

This is the altered structure so that it matches your expected packed output:

#[derive(PackedStruct, PartialEq, Debug)]
#[packed_struct(size_bytes="4", bit_numbering="msb0", endian="lsb")]
pub struct BigIntsLsb {
    #[packed_field(bits="5:7")]
    pub val1: Integer<u8, packed_bits::Bits3>,
    #[packed_field(bits="13")]
    pub val2: bool,
    #[packed_field(bits="31:16")]
    pub val3: Integer<u16, packed_bits::Bits16>,
}

And its layout:

BigIntsLsb (4 bytes)

Decimal
[7, 4, 239, 190]

Hex
[0x7, 0x4, 0xEF, 0xBE]

Binary
[0b00000111, 0b00000100, 0b11101111, 0b10111110]

 val1 | bits   5:7   | 0b111              | "7"
 val2 | bits  13:13  | 0b1                | "true"
 val3 | bits  16:31  | 0b1110111110111110 | "48879"

[janbraiins]

Thank you for explanation, I have updated the test case, however I believe this is still a bit counter intuitive (that doesn't mean that I cannot live with it). See my updated branch that actually uses lsb0 ordering.

I believe the source of confusion is from which byte you start numbering individual bits. In my example the structure should be serialized as byte array is [0x07, 0x04, 0xEF, 0xBE]. When this is interpreted as a 32-bit number with LSB endianness, it should appear as 0xBEEF0407 to the machine, I/O peripheral, or similar piece of hardware. Now the question, would you also expect that lsb0 bit ordering will start from the lowest byte of the structure? I would expect that. Therefore the digit 7 should occupy bits 2:0.

Anyway, I don't want to open an argument about this. I am very happy that this rust crate exists. Just my $0.02 to it.

To recap: the confusing part is that if one requests 'LSB' endianness it should be a hint for the layout of the entire structure not just the default serialization layout of individual field. However, with bit-field level layout this invariant no longer holds.