I agree. A different question though is why FT_UINT64 isn't in the same group as the other FT_UINT* ones. (And of course FT_INT64 in FT_INT*)
Also, what about FT_NONE? Lots of current duplicate fields have one of the duplicates as FT_NONE - why I don't know, but I don't think that breaks filtering input. (though I'm not positive about that) -hadriel On Feb 21, 2014, at 2:15 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Feb 21, 2014, at 10:43 AM, Hadriel Kaplan <hadriel.kap...@oracle.com> > 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 <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe