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ń <deso...@gmail.com> wrote: > On Thu, Jul 30, 2020 at 9:18 AM Roland Knall <rkn...@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-requ...@wireshark.org?subject=unsubscribe
