Wireshark · Wireshark-dev: Re: [Wireshark-dev] Question / nit / ocd trigger

[chuck c <bubbasnmp@xxxxxxxxx>]

Not a why but when:

https://gitlab.com/wireshark/wireshark/-/commit/5110b21fd8cba19554f0c4f7a52e96af3acf4927

typedef struct _packet_info {
  char *srcip;
  int ip_src;
  char *destip;
  int ipproto;
  int srcport;
  int destport;
  int iplen;
  int iphdrlen;
} packet_info;

Looks like "dest" was consistent in the beginning.

On Mon, May 24, 2021 at 8:01 PM John Thacker <johnthacker@xxxxxxxxx> wrote:

On Mon, May 24, 2021 at 12:19 PM Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

On Mon, 24 May 2021 at 16:22, Jason Cohen <kryojenik2@xxxxxxxxx> wrote:

One thing that has bothered me for years has been the TCP flags filters.

...

Is there history, reasoning for this?  Should there be some level of consistency?  I certainly do not advocate for tcp.flags.acknowledgement or tcp.flags.syncronize.  However, I think it would be reasonable for reset and push to be replaced with "rst" and "psh" respectively.  Perhaps an alias to allow the spelled out filters to continue to work.

While consistency is good and the change seems simple, it will break many existing workflows and "muscle memory" and all the many guides\manuals etc. out there.  An alias would help going forwards but I think users may still become confused.

I class this as the type of change that really needs a time machine to allow the correct implementation at the start or maybe a Neuralyzer (https://meninblack.fandom.com/wiki/Neuralyzer)

 

For me, from a dissector development standpoint, the all time winner in this category is "why does packet_info use src and dst for addresses, but srcport and destport for ports, why isn't it dstport?"

John Thacker

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe