Re: Why tvb_get_bits() assumes Big Endian?

[John Thacker <johnthacker () gmail com>]

On Thu, Jul 30, 2020 at 11:56 AM Tomasz Moń <desowin () gmail com> wrote:

> On Thu, Jul 30, 2020 at 3:35 PM Filipe Laíns <lains () archlinux org> wrote:
> > For this reason I decided to drop it in favor of tvb_get_bits_array
> > + pletoh*. It is simple enough to be used standalone.
>
> This looks like a workaround to me, not a proper solution.
>
> To me the bit level order within a single byte seems clear - it's up
> to the tool that provides data to Wireshark to handle it. Wireshark
> job starts at the byte (octet) level.

Maybe here, but consider the FDDI dissector, along with H.223 and BMC, all
of which include wsutil/bitswap.h and call bitswap_buf_inplace()
> From what I recall of FDDI, that's because FDDI had the opposite bit order
of
Ethernet. Also it used MAC addresses and allowed bridging to Ethernet with
ARPs, so the MAC addresses in the ARP were in the opposite bit order as
the same MAC addresses in the FDDI header.

Certainly there is a special place reserved for people who come up with
this,
but if you really do need to reverse the bit level order for an array of
bytes, there
is already a function for that.

John Thacker

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe