Wireshark mailing list archives
Re: What ftypes are "compatible" enough for duplicate fields?
From: Guy Harris <guy () alum mit edu>
Date: Fri, 21 Feb 2014 15:27:42 -0800
On Feb 21, 2014, at 11:43 AM, Hadriel Kaplan <hadriel.kaplan () oracle com> wrote:
A different question though is why FT_UINT64 isn't in the same group as the other FT_UINT* ones.
Because Wireshark was developed in an era where the majority of platforms on which it ran were 32-bit, so we made the integral types 32-bit (not all C compilers, at the time, supported 64-bit integral data types on 32-bit platforms), and later added 64-bit integral types - and we were probably thinking with a 32-bit mindset when we did that, as I think that predated x86-64, so the majority of platforms, at least by "number of seats" rather than by counting each ISA, in both its 32-bit and 64-bit versions, as a platform, were probably still 32-bit. The "value" union member of a "struct fvalue" is a union of a number of types, the biggest of which are, on an ILP32 system, 128 bits (IPv6 address, GUID), so it's not as if representing all integral values as 64-bit would increase the memory usage of protocol trees. It might increase memory bandwidth usage (but, with caches in the way, maybe not), and might lengthen code paths a bit, but I don't know how big of a hit that'd be. It might be interesting to try, for example, running a huge capture file through TShark with separate union members for up-to-32-bit and 64-bit integral values, on a system with a 32-bit processor, and see whether it makes a difference worth caring about. If not, we might want to consider storing all integral values as 64-bit, and having FT_{U}INT64 in the same groups as the other FT_{u}INTn types.
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.
If foo.bar is of type FT_UINTn, you could do "foo.bar == 17"; I'm not sure you can do anything with an FT_NONE field other than test for its existence (if you want to compare it with something, make it FT_BYTES). So I'm not sure what it'd mean if a dissector had both FT_something and FT_NONE versions of a field. ___________________________________________________________________________ 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-request () wireshark org?subject=unsubscribe
Current thread:
- What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Evan Huus (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Evan Huus (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Guy Harris (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Guy Harris (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Guy Harris (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Hadriel Kaplan (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Evan Huus (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Guy Harris (Feb 21)
- Re: What ftypes are "compatible" enough for duplicate fields? Evan Huus (Feb 21)