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.