Should an IPv4 netmask be its own fieldtype?

[mmann78 () netscape net]

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