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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe