On Fri, Feb 21, 2014 at 7:13 PM, Hadriel Kaplan <[email protected]> wrote: > > On Feb 21, 2014, at 6:27 PM, Guy Harris <[email protected]> wrote: > >> >> On Feb 21, 2014, at 11:43 AM, Hadriel Kaplan <[email protected]> >> 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)
That's not strictly wrong, just unnecessary. The subtree item can just be text, as long as the actual data item is still added to be filterable. ___________________________________________________________________________ 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
