Re: Should an IPv4 netmask be its own fieldtype?

[Evan Huus <eapache () gmail com>]

A pure netmask (without an associated address) is representable as
just a UINT8. Would it be terrible to write `protocolXYZ.netmask ==
24`?

On Wed, Sep 30, 2015 at 10:59 PM,  <mmann78 () netscape net> wrote:
> There's a discussion in a patch review
> (https://code.wireshark.org/review/10438/), that I think should get more
> visibility.
>
> The question is "should an IPv4 netmask field be its own fieldtype?"  The
> main problem being that netmasks are being treated as IPv4 fields and are
> attempted to be named resolved, which shouldn't be.  The original patch
> created an "IPv4_MASK" field type to handle this.  Recent discussions about
> field types (on this mailing list and other patch reviews) have consistently
> resulted in new "display types" being created over new field types.
> Following this, I amended the original patch to use a "display type" instead
> of a field type.  The argument for the field type by the original patch
> author (Jeffrey Smith, CCed here in case he's not on -dev) is:
>
> "... the display filter "protocolXYZ.netmask == 10.0.0.1/24" is currently
> valid but semantically makes no sense.  Also, I think "protocolXYZ.netmask
> == /24" does make sense but does not work.  This change makes the sensible
> thing happen in those cases, but a display-only change would not have the
> same effect."
>
> I'm not familiar enough with using this filter notation or know how popular
> it is to know how much this impact should be considered.  But I know there
> are others on the list that may have stronger and more educated opinions.
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe