On Thu, 2020-07-30 at 17:55 +0200, Tomasz Moń wrote:
> On Thu, Jul 30, 2020 at 3:35 PM Filipe Laíns <lains@xxxxxxxxxxxxx>
> 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.
>
> > I would actually like to see tvb_get_bits* throw an error
> > on ENC_LITTLE_ENDIAN as it is clearly not supported.
>
> Yes, it would be better to throw an error than to silently assume Big
> Endian. However, the best would be if it simply worked with
> ENC_LITTLE_ENDIAN.
>
> In fact, if you check the history, you'll notice that the initial
> implementation did call DISSECTOR_ASSERT_NOT_REACHED(); when called
> with little endian [1].
>
> [1]
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=b688f9154aacf9c2f30dc6c715bc115a05e9fcef
I think it would be reasonable to say that cases which need such
special handling can do it themselves. Wireshark should still provide
all the routines required to make this work, but I don't think it needs
to necessarily provide a function for very specific use cases.
With that said, if we want to indeed support this then we need new
functions. We can't touch the current signature as that will break the
ABI.
My proposal would be to make tvb_get_bits* respect little endian for
the value itself and add correspondent tvb_get_network_bits* methods
that would treat the buffer as little endian. What do you think?
Would adjusting the behavior of tvb_get_bits* be considered a breaking
change? I mean, this behavior is not documented.
Filipe Laíns
Attachment:
signature.asc
Description: This is a digitally signed message part