Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 48555: /trunk/epan/ /trunk/epan/: va

From: Bill Meier <wmeier@xxxxxxxxxxx>
Date: Tue, 26 Mar 2013 08:40:28 -0400
On 3/25/2013 8:37 PM, guy@xxxxxxxxxxxxx wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=48555

User: guy
Date: 2013/03/25 05:37 PM



Guy;

I'm curious why you added the following test in the recent value_string.c patch

      if (first_value > vs_p[i].value) {
g_warning("Extended value string %s forced to fall back to linear search: entry %u, value %u < first entry, value %u",
                  vse->_vs_name, i, vs_p[i].value, first_value);
        type = VS_SEARCH;
        break;
      }


Do you feel that the "special case" described in the comments (see extract below) should be dis-allowed (maybe because it's a bit of a hack) ?

If so, ISTR there are some value string arrays which will need to be re-ordered.

Bill




/* Note: The value_string 'value' is *unsigned*.
 *
 *   Special case:
 *    { -3, -2, -1, 0, 1, 2 }  will be treated as "ascending ordered"
                               (altho not really such)
 *                             thus allowing as a 'direct' search.
 *
 *   Note:
 *    { -3, -2, 0, 1, 2 } and { -3, -2, -1, 0, 2 } will both be
                                considered as "out-of-order with gaps"
 *                              thus requiring a 'linear' search.
 *    { 0, 1, 2, -3, -2 } and { 0, 2, -3, -2, -1 } will be considered
                                "ascending ordered with gaps"
 *                              thus allowing a 'binary' search.
 */