Wireshark-bugs: [Wireshark-bugs] [Bug 7933] Add ability to reverse FT_BYTES for display
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Mon, 29 Oct 2012 12:16:56 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7933

--- Comment #2 from Guy Harris <guy@xxxxxxxxxxxx> 2012-10-29 12:16:55 PDT ---
(In reply to comment #0)
> Currently, the encoding argument of proto_tree_add_item() is ignored for
> FT_BYTES fields. Such fields are always displayed big-endian.

An FT_BYTES field is a byte array, not a multi-byte number, so it doesn't
really have an endianness - the bytes are displayed in the order in which they
appear in the array.

> Some USB classes (i.e., Video) define bitmap ("bmXXX") fields whose length is
> specified within a message (a kind of FT_UINT_BYTES).

Or, alternatively, like a variable-length FT_UINT variable supporting arbitrary
lengths, which *would* have an endianness.

If the size of the field has an upper bound <= 8 bytes, it could be implemented
as FT_UINT if the upper bound is <= 4 and an FT_UINT64 if it's > 4 but <= 8 -
fetch its value a byte at a time (or add "tvb_get_ntohlen()" and
"tab_get_letohlen()" routines that take a length and do it for you).

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.