Thanks Jakub for historic I think a good idea is revert to use "standard" API or write a tools for convert old dissector to new API...
Cheers On Tue, Sep 18, 2018 at 6:05 PM Jakub Zawadzki <darkjames...@darkjames.pl> wrote: > 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. > ___________________________________________________________________________ > 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