Re: address to string optimization

[Guy Harris <guy () alum mit edu>]

On Jan 16, 2015, at 11:34 AM, mmann78 () netscape net wrote:

> I still like the idea of the address types being "centrally registered" (in epan directory) and not put into the 
> dissector code, mostly because many of the address types are used in multiple dissector/protocols.

Perhaps libwireshark should export a core set of AT_ values and, if it turns out to be useful, allow dissectors to 
register their own private address types as well ("private" meaning "nobody else cares about them", so that there's no 
advantage to putting code for them in the libwireshark core).

I'd still check out switches and ifs that check for AT_ values and try to make them call functions instead.

> You may also introduce epan dependencies (like from proto.c) with the dissectors, and I think that should be avoided 
> (yes I know some exist, but I've been working to slowly remove them).

Presumably meaning "core libwireshark code in the epan directory being dependent on dissector code in epan/dissectors".

> I just really like the idea that a series of properly structured function callbacks could eliminate a lot of the 
> sprintf processing of the "address to string" and drastically improve performance (since almost all packets do some 
> time of address to string processing).  Also included could be standards in displaying "address string" + "address 
> name resolution" formatting.  Personally I like the %s (%s), for address string then resolution,

...although that's the opposite of what we do for enumerated-type numeric values, where we give the name, followed by 
the numeric value in parentheses.
___________________________________________________________________________
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