Wireshark-dev: Re: [Wireshark-dev] tools/check[hf|APIs|filtername].pl need updating?
Hi,
W dniu 2018-09-18 16:56, Maynard, Chris napisał(a):
While investigating the transum-related crash, I had suspected some
unregistered hf's and ran the various tools like checkhf.pl. I then
noticed that a number of dissectors seemed to have changed a bit from
what I was used to before (...)
These changes are quite old. For udp I did it in Aug 2013
(88eaebaedf2e19c493ea696f633463e4f2a9a757).
some wireshark-dev threads:
- https://www.wireshark.org/lists/wireshark-dev/201307/msg00222.html
- thread continuation:
https://www.wireshark.org/lists/wireshark-dev/201308/msg00035.html
Nobody stopped me that time.
And I guess I missed the reasoning behind the restructuring, but what
is the purpose/benefit of this restructuring
To sum up:
Restructuring idea was to remove usage of int hf_foo, so you would need
only to declare header_field_info hfi_foo (unfortunate, you still need
to do it on top of file).
Benefit is no more ints, so:
- proto_tree_ api checks if you passed header_field_info structure,
- You don't need to declare int hf_foo = -1; (bonus: binary size
smaller 4 bytes per hf),
- no need for table lookup in proto_tree_add_*
and use of HAVE_HFI_SECTION_INIT?
Idea was that HFI_INIT(proto_bar) would put all protocol hfi's into
single binary section. This way wireshark could auto-register these
fields
without need of some indirect array (bonus: binary size smaller by
sizeof(void *) per hfi).
After 5 years simple grep shows that only 36 dissectors are using
NEW_PROTO_TREE_API, so it seems that this API is not well known or not
liked.
If it makes problem I would suggest to drop it.
Alexis suggested the same in 2015:
https://www.wireshark.org/lists/wireshark-dev/201508/msg00087.html
Jakub.
