Re: What ftypes are "compatible" enough for duplicate fields?

[Evan Huus <eapache () gmail com>]

On Fri, Feb 21, 2014 at 7:13 PM, Hadriel Kaplan
<hadriel.kaplan () oracle com> wrote:
> 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)

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 <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