Re: [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c packet-gadu-gadu.c ...

[Jakub Zawadzki <darkjames-ws () darkjames pl>]

On Fri, Nov 08, 2013 at 01:27:40AM +0100, Joerg Mayer wrote:
> On Fri, Nov 08, 2013 at 01:03:47AM +0100, Jakub Zawadzki wrote:
> > After r53150 it works with GCC, at least on my Linux ;-)
>
> And after another commit it also works on my system (32-bit Linux with GCC 4.8.2),
> so I decided to make it easier to play with this.

> Turns out my mint dissector had an unused element ;-)

Yeah, no longer need for checkhf.pl (which in fact doesn't work with new style
dissectors).

> Hopefully I'll be able to test on windows tomorrow so if a few more tests
> turn out good results the "old" code could be removed.

Windows MSVC doesn't support __attribute__((section)) it has their own
way [1]. It could work with mingw/cygwin.

Even if we implement it for Windows, we can't remove hfi array
completely. There might be systems on which it won't work.
It's good opt-in (binary can be smaller by about 1-2 MB, which will
give us minimally faster startup), but not portable.

We could not emulate arrays using section, but write it explicit (100% portable!):

        enum {
                HF_FOO = 0,
                HF_BAR
        };

        struct header_field_info proto_hfi[] = {
                { field_foo },
                { field_bar }
        };

        proto_tree_add_item( &proto_hfi[HF_FOO] );
        proto_tree_add_item( &proto_hfi[HF_BAR] );

but to make maintaince of assigning good index to hfi easier, we'd need C99:

        struct header_field_info proto_hfi[] = {
                [HF_FOO] = { field_foo },
                [HF_BAR] = { field_bar }
        };

Which is not supported at least in MSVC, anyway seperate variable for each hf looks IMHO nicer.

[1] http://stackoverflow.com/questions/3808053/how-to-get-a-pointer-to-a-binary-section-in-msvc
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe