Comment # 12
on bug 8461
from Sebastiano Di Paola
(In reply to comment #11)
> (In reply to comment #10)
> > Patch looks fine, but I'm hesitant to merge the custom channel_string bit -
> > str_to_val is something we really ought to be providing in the Wireshark API.
> >
> > Do you mind waiting a bit until somebody has time to code that up?
>
> Alternatively, I'd be perfectly happy to accept a secondary patch that adds
> this functionality :)
>
> Your existing code looks fine, I suspect it just needs to be transplanted
> into epan/value_string.[ch] and tweaked a bit to make it generic.
it will be a pleasure for me ;-) to add this functionality in the wireshark
API.
But looking at the code in epan/value_string.[ch] some troubles with function
naming migth appear...
i.e. match_strval and match_strval_idx are IMHO more naturally name associated
to the function i'm going to implement (matching a string to a val)..but are
already used to do the opposite function so (matching a val to a string)
What about a wrapper for already existing functions in order not to break
interface compatibility, and then create a new naming convention making
deprecated match_strval and match_strval_idx and similar function ..replacing
them with
match_val2str, match_val2str_idx, match_str2str, match_str2str_idx, and
match_str2val and match_str2val_idx as a possible naming suggestion?
Besides that more "naturally" string_value name for data structure used by
match_str2val will collide with variable name used inside packet-edonkey.c.
Any hints/ suggestion? (Maybe opening a ticket/bug on this specific topic can
be the first step)
You are receiving this mail because:
- You are watching all bug changes.
