On Feb 21, 2014, at 10:43 AM, Hadriel Kaplan <[email protected]> wrote:
> So this then:
> - FT_INT8, FT_INT16, FT_INT24 and FT_INT32
> - FT_UINT8, FT_UINT16, FT_UINT24, FT_UINT32, FT_IPXNET and FT_FRAMENUM
I'd be tempted to consider FT_IPXNET and FT_FRAMENUM to be *sui generis*; they
might be displayed as unsigned integers, but, unlike FT_UINTn, where they're
just unsigned integers of different sizes, FT_IPXNET is an IPX network number
and FT_FRAMENUM is a frame number, so I'm not sure it makes sense to have, for
example, a field that's sometimes an integer from the packet and sometimes a
frame number.
> - FT_UINT64 and FT_EUI64
Same there - an EUI-64 is a specific type of value.
> - FT_BYTES, FT_UINT_BYTES, FT_AX25, FT_ETHER, FT_VINES, FT_OID and FT_REL_OID
And same here - I'd go for
- FT_BYTES and FT_UINT_BYTES
- FT_AX25 (this is an AX.25 address, and is unlikely to be anything
else)
- FT_ETHER (MAC-48, and unlikely to be anything else)
- FT_VINES (Vines address)
- FT_OID and FT_REL_OID (I'm guessing that a given OID could be
represented either way; if not, maybe they should be separate)
> - FT_ABSOLUTE_TIME and FT_RELATIVE_TIME
Absolute times are time stamps; relative times are "n seconds from now"-type
values. I'd split them as well.
___________________________________________________________________________
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
