Wireshark mailing list archives
Re: What ftypes are "compatible" enough for duplicate fields?
From: Hadriel Kaplan <hadriel.kaplan () oracle com>
Date: Fri, 21 Feb 2014 19:13:31 -0500
On Feb 21, 2014, at 6:27 PM, Guy Harris <guy () alum mit edu> wrote:
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. [snip]
Oh I guessed the history, but wasn't sure if it actually made a difference for the purposes of ftype "equivalence" with respect to duplicate fields. I.e., whether anything messes up from it or not in terms of the filters. (without changing any code)
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.
The few such duplicates I checked basically used the FT_NONE field for a tree item; while the "real" ftype field was used for actual data. (if I recall correctly) -hadriel ___________________________________________________________________________ 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)