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 <johnthac...@gmail.com> wrote:
> On Mon, May 24, 2021 at 12:19 PM Graham Bloice <
> graham.blo...@trihedral.com> wrote:
>
>>
>>
>> On Mon, 24 May 2021 at 16:22, Jason Cohen <kryojen...@gmail.com> 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@wireshark.org>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
