On Jan 16, 2015, at 6:04 AM, mmann78@xxxxxxxxxxxx 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.
