[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

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@xxxxxxxxx> wrote:

On Thu, Jul 30, 2020 at 9:18 AM Roland Knall <rknall@xxxxxxxxx> 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