I forgot to add: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4478
On Thu, 30 Jul 2020 at 09:22, Graham Bloice <graham.blo...@trihedral.com> wrote: > 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 > -- 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
