Hi,
I can see both points of view. However, I think we can retain the code as is for ENC_NA (== ENC_BIG_ENDIAN) and add code to handle the ENC_LITTLE_ENDIAN case to it. This should not break any existing code, the choice ENC_NA = ENC_BIG_ENDIAN was made in that light.
I think it's not in there now because we never encountered a protocol like this, AFAIK.
Thanks,
Jaap
> On 30 Jul 2020, at 09:26, 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.