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
cheers
On Thu, Jul 30, 2020 at 8:30 AM Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> Let’s put a hypothetical here, a 7 bit value spanning 2 octets:
>
> 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | | | | | | | 6| 5| 4| 3| 2| 1| 0| | | |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> This would be the typical interpretation, as seen in network protocols.
>
> Your suggestion is that the interpretation can also be:
>
> 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | | | | | | | 1| 0| 6| 5| 4| 3| 2| | | |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
This is not what I wanted to write. Assuming you meant two octets, and
the bitmask on the 16-bit value is 0x1FC0 then the alternative
interpretation would be:
15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | | | | | 4| 3| 2| 1| 0| 6| 5| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> Here the first interpretation is a simple matter of mask and shift, the second interpretation is somewhat more involved. Since the first interpretation is common in network protocols (and efficient to handle) the code was made with that in mind.
Is the complexity the only reason? I prefer the complex things to be
in the common code and not in individual dissectors.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
