Comment # 6
on bug 7933
from Guy Harris
(In reply to comment #5)
> I see use cases for displaying a range of bytes in reverse order in the
> protocol tree. I suggest however to create a new ENC_ type for it, like
> ENC_REVERSE. I agree that we should not overload the precisely defined
> meaning of little and big endian, which doesn't cleanly apply for arrays of
> bytes.
If it's just an array of bytes, such that the byte that appears with the lowest
byte offset in the packet is the first byte in the array and the byte that
appears with the highest byte offset in the packet is the last byte in the
array, and the right way to display it is to show, in order, the last byte,
followed by the next-to-last byte, followed by ..., followed by the second
byte, followed by the first byte, that should probably be controlled by the
"display" field of the header_field_info structure (that's the field that's a
BASE_ value for integers).
If it's an array of bytes where the conceptually-last element of the array
appears earliest in the packet and the conceptually-first element of the array
appears latest in the packet, so that the bytes appear in *reverse* order in
the packet, that would be an ENC_ value.
What are the use cases in question? Are they all like the first or second of
those, or are some of them like the first and others like the second?
You are receiving this mail because:
- You are watching all bug changes.