On Oct 19, 2011, at 4:28 PM, Bill Meier wrote: > No fixes required: > FT_RELATIVE_TIME > FT_FRAMENUM > FT_PCRE
...because they're currently not supported by proto_tree_add_item(). FT_FRAMENUM never will be, and FT_PCRE is, I think, a type used only in filter expressions (a field cannot have that type), but, at some point, we'll probably support FT_RELATIVE_TIME in a fashion similar to FT_ABSOLUTE_TIME, at which point it'll require a byte order. There are no *current* calls that need to be fixed. > TBD/ToDo: > FT_ETHER Not yet fixed: Should always be ENC_NA ??? Yes. A MAC-48 address is just a sequence of 6 octets, so no byte order. > FT_PROTOCOL Not yet fixed: Should be ??? ENC_NA. It's like FT_NONE. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
