Hi,
Let’s put a hypothetical here, a 7 bit value spanning 2 octets:
15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | | | | | 6| 5| 4| 3| 2| 1| 0| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
This would be the typical interpretation, as seen in network protocols.
Your suggestion is that the interpretation can also be:
15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | | | | | 1| 0| 6| 5| 4| 3| 2| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Here the first interpretation is a simple matter of mask and shift, the second interpretation is somewhat more involved. Since the first interpretation is common in network protocols (and efficient to handle) the code was made with that in mind.
Thanks,
Jaap
> On 30 Jul 2020, at 08:06, Tomasz Moń <desowin@xxxxxxxxx> wrote:
>
> Hello,
>
> The tvb_get_bits() function family contains following comment:
> /* note that encoding has no meaning here, as the tvb is
> considered to contain an octet array */
>
> I don't understand the reason. What am I missing?
>
> The actual octets in tvb contain the bits ordered as expected, so the
> MSB/LSB-first problem within the octet itself does not apply (and I
> think this is what the comment refers to). However, when the bit field
> (e.g. 11 bits) spans across multiple octets, then the endianness does
> matter (i.e. which of the two octets contains the more significant
> part of the 11-bit value). Simply assuming Big Endian at the
> cross-octet boundary prevents USB HID dissection from using
> tvb_get_bits() directly because USB uses Little Endian.
>
> Best Regards,
> Tomasz Moń
