2013/7/30 Joerg Mayer <jma...@loplof.de>: > On Mon, Jul 29, 2013 at 10:42:02PM +0200, Jakub Zawadzki wrote: >> On Mon, Jul 29, 2013 at 01:25:41PM -0700, Guy Harris wrote: >> > >> > On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki <darkjames...@darkjames.pl> >> > wrote: >> > >> > > Is anyone attached to hf_ variables? ;) >> > > >> > > There's no real need of them, and we can just replace them with >> > > header_field_info structure. >> > >> > I.e., pass a pointer to the relevant structure, rather than an array index >> > into an internal array that can supply that pointer? >> >> Yes. >> >> > I'm not sure there's a compelling reason (other than the effort involved >> > in converting code) to keep the variables. >> >> Being devil's advocate I think there's no good reason to convert it. >> Saving few CPU cycles by not doing: >> - load variable into memory >> - avoid PROTO_REGISTRAR_GET_NTH() >> >> and some cycles on startup + max 2-3 MB less in binary doesn't seems like >> good deal >> against converting 90% of dissectors codebase :) > > If we don't loose functionality, I'd probably like to get rid of the extra > variables (both ett_ and hf_) as it makes coding a bit more convenient. > In the ett_ case: currently expansion is done similarly for all elements > using the same ett variable, how would that be done without these vars? > > Can you give a sample diff how a dissector would need to be changed? > Also: What would be the migration plan: All at once or incremental? If we plan making such big changes which require touching practically every dissector, it would be nice to migrate dissection related global variables into a context structure which would allow us to run several dissections on several files in one binary.
Cheers, Balint ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
