Comment # 7
on bug 7933
from Evan Huus
(In reply to comment #6)
> (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?
My understanding is that this bug was filed for the second case, but I'll let
Steve verify.
You are receiving this mail because:
- You are watching all bug changes.