Wireshark · Wireshark-dev: Re: [Wireshark-dev] Use val_to_str_ext() & friends to access sminmpec_values[]

[Bill Meier <wmeier@xxxxxxxxxxx>]

Bill Meier wrote:
> Jakub Zawadzki wrote:
> > Hi,
> >
> > On Fri, Sep 17, 2010 at 02:00:44PM -0400, Bill Meier wrote:
> > > Anders Broman wrote:
> > > > Is the script "fixed" to fill out any "holes" in the list with "unasigned"?
> > > > That would be the most efficent use...

> > > If I do this, match_strval() against the sminmpec list will no longer 
> > > return NULL for a "missing" entry (other than "past the end").

> > Can we use NULLs instead of 'unasigned'?
> >
> > All value_string_match_t functions (except of _match_strval_linear(), which is just wrapper to match_strval())
> > are using vs->length already.
> >
> > It might not work when wireshark want to iterate through values.

> I considered using NULL, but came to the conclusion that 
> match_strval_ext doing a linear search could/would terminate early 
> because of the NULL (which is what I think you are saying above).
>
> However: I think you're on the right track: for "extended" value strings 
> I'll just create a version of the linear match which uses vs->length 
> instead of checking for NULL.


I decided to use "(Unknown)" instead of NULL for the string value for 
entries used to fill "gaps" in sminmpec.

The main reason: there's code that assumes that value_strings (even 
those referenced by value_string_ext) end with a NULL strptr.

I could have changed that code when dealing with value_string_ext, but 
decided I shouldn't change the (long standing) semantics of value_strings.

If the use of "(Unknown)" to fill in the gaps for sminmpec proves to be 
a problem for some reason, reverting will just cause a binary search to 
be used which isn't really a problem.