Re: Why tvb_get_bits() assumes Big Endian?

[Graham Bloice <graham.bloice () trihedral com>]

Personally, I would argue that when the bits aren't in order then they
aren't bits in an octet array, instead they are bits in words, or longs or
long longs with endianess.

There's a special place reserved for folks that write protocols like that.

If the code can sensibly be arranged such that the ENC_NA path is no worse
than before changes to support ENC_LITTLE_ENDIAN  and ENC_
ENC_BIG_ENDIAN  would be OK, but changing the behaviour of the
encoding argument may break existing dissectors.


On Thu, 30 Jul 2020 at 08:27, Tomasz Moń <desowin () gmail com> wrote:

> On Thu, Jul 30, 2020 at 9:18 AM Roland Knall <rknall () gmail com> wrote:
> > Putting the complexity in the common code will increase the complexity
> for a lot of other stuff which relies on this functionality. Also you run
> the risk of increasing dissection time for more protocols, then if you
> handle it specifically.
> > That would be my reasoning against it
>
> Having the function take quite important parameter (encoding) and not
> using it at all is pretty bad. When someone tries to use
> tvb_get_bits() with ENC_LITTLE_ENDIAN the issue becomes apparent.

-- 
Graham Bloice

___________________________________________________________________________
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