Re: address to string optimization

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

On Jan 16, 2015, at 6:04 AM, mmann78 () netscape net wrote:

> A few weeks ago I stumbled across the following comment in address_to_str.c:
>  
> /*XXX FIXME the code below may be called very very frequently in the future.
>   optimize it for speed and get rid of the slow sprintfs */
> /* XXX - perhaps we should have individual address types register
>    a table of routines to do operations such as address-to-name translation,
>    address-to-string translation, and the like, and have this call them,
>    and also have an address-to-string-with-a-name routine */
> /* XXX - use this, and that future address-to-string-with-a-name routine,
>    in "col_set_addr()"; it might also be useful to have address types
>    export the names of the source and destination address fields, so
>    that "col_set_addr()" need know nothing whatsoever about particular
>    address types */
> /* convert an address struct into a printable string */
>  
>  
> This all sounded like a very good idea (mostly the removal of the sprintfs), but there was a lot of "prep" work 
> involved to make "address registering" easier to create (the "to string" function were a bit scattered/haphazard).  I 
> believe the "prep" work is now complete.  The problem I have is that I can't quite get my head around what's needed 
> for "address registering".  I assume it would be modeled loosely after field type registration.
>  
> If the author of the comment is still around, I would gladly work with them to try to come up with address 
> registering.  Mostly what I'm volunteering for is "filling out the tables" once a few address types have been figured 
> out/added.  This also seems to be a preferred solution to the current USB addressing (compare) issues.

I think the author of the comment is named "Ronnie Sahlberg+Guy Harris+possibly some others". :-)

I.e., I think Ronnie's the author of the first part of the comment, and I might have been the author of the second and 
third parts, but I'm not sure.

"Address type registration", at least as I'd do it, would allow a dissector to register an address type with those 
routines and get, in response, a numerical value to use as the type field in an address structure.  This would be a bit 
different from the way field types *currently* work - currently, a fixed set of FT_ values are defined in an enum in 
epan/ftypes/ftypes.h, rather than being numerical values assigned at startup time.

So the AT_ enums defined in epan/address.h would no longer be defined there.  Yes, this means that all the case 
statements and if statements checking for AT_ values would have to be changed, perhaps by virtue of having additional 
functions provided for registered address types, but that's arguably a Good Thing, as it means fewer places would need 
to be changed if a new address type were introduced.
___________________________________________________________________________
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