ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 4478] Implement little endian support for tvb_get_bits[16|

Date: Mon, 3 Jan 2011 14:18:14 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4478

--- Comment #5 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2011-01-03 14:18:09 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> Reading again my description, I realize it's biased toward the result I needed
> from the data I had to analyze.
> Which is:
> - bit fields smaller than a byte
> - 2-bytes words in LE byte ordering
> - each byte using BE bit ordering
> 
> So I needed to find a way to extract, say, 0x3 from {0x80, 0x1}, given offset =
> 7 bits and length = 2 bits.
> 
> Maybe this won't fit in just one function, and byte ordering should be "fixed"
> independently of bit field extraction...

OK, so there are 4 combinations of BYTE/bit ordering: BE/be, BE/le, LE/be and
LE/le.  Surely le (little-endian bit ordering) is not very common or useful
(others may disagree?), so the two most likely useful cases are BE/be (which we
already have) and LE/be, which is what you're proposing.  OK, got it now.

And looking back at my examples above for LE/be, I guess I really didn't get it
right either as I skipped bits before reconstructing the LE value and then
shifting as needed.  I think the following for LE/be is correct though (but
feel free to check it to be sure):

- file data
  0x12 0x34 0x56 0x78 0x9A
 - bit_offset, no_of_bits = result // comments
   0, 32 = 0x78563412 // regular conversion of 4 first bytes
   4, 24 = 0x00856341 // Take 24 bits, skipping the 1st 4 bits of the 1st byte
   4, 32 = 0xA7856341 // Take 32 bits, skipping the 1st 4 bits of the 1st byte

So ... is this what your patch implements?  And hopefully this is the behavior
everyone else would expect as well ... or should we take into account those
other cases of BE/le and LE/le?

Another idea might be to use a bitmask, which would also allow for
non-consecutive bits to be obtained as a single value.  For example (here I
assume BE/be):
- file data
  0x12 0x34 0x56 0x78 0x9A
- byte_width, mask // comments
  4, 0xffffffff = 0x78563412 // take all 32 bits of the 1st 4 bytes
  4, 0x0ffffff0 = 0x00234567 // Take 24 bits, skipping the 1st 4 bits
  5, 0x0ffffffff0 = 0x23456789 // Take 32 bits, skipping the 1st 4 bits

So far that didn't buy us much because I used masks to show how you could get
the same thing as with bit widths, but what if you wanted to get
non-consecutive bits, like every other bit (just as an example):
- byte_width, mask // comments
  4, 0xaaaaaaaa = 0x1416 // take 16 bits (every other one) of the 1st 4 bytes

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.