Re: hfinfo.string const initializer / change VALS by preference ?

[Harald Welte <laforge () gnumonks org>]

Hi Jakub,

thansks a lot for your help.

On Fri, Jun 18, 2010 at 10:48:07AM +0200, Jakub Zawadzki wrote:
 
> 1/ You can use value_string_ext (and or hfinfo.display with BASE_EXT_STRING)
>
>   static const value_string vs_vendor0[] = { ... }; /* pref_vendor == 0 */
>   static const value_string vs_vendor1[] = { ... }; /* pref_vendor == 1 */
>
>   static int pref_vendor = 0;
>   static value_string_ext vse_vendor0 = VALUE_STRING_EXT_INIT(vs_vendor0); 
>   static value_string_ext vse_vendor1 = VALUE_STRING_EXT_INIT(vs_vendor1);
>   static value_string_ext vs_vendor = VALUE_STRING_EXT_INIT(vs_vendor0); /*needed?*

[...]

I have now decided to use value_string_ext and override the .match function to
a function that first checks in the currently selected vendor-specific value_string
array, and if nothing is found it checks the array that is specified by the TS
12.21 specification.

This combines the strength of all approaches:
* no memcpy'ing the value_string arrays around
* vendor-specific definitions can override the standard (needed for those
  who even override standard message types or IEIs)
* very little impact when preference changes, simply re-assing the vs_ext->vs
  and vs_ext->length parameters and everything works as indicated.

Now my only major problem with submitting this for inclusion to wireshark
is that all included the A-bis OML TLV parser definitions are making heavy
use of indexed array initializers, i.e.

struct tlv_def foo[] = {
        [0x03]  = { TLV_TYPE_FIXED, 2 },
        [0x33]  = { TLV_TYPE_TLV, 0 },
};

And I don't really know of a good way to re-write the code without using
them.  And in case you ask yourself why I wrote them that way: They are
copied from the OpenBSC codebase.

> Btw. OpenBSC is great project!

thanks! wireshark too ;)

-- 
- Harald Welte <laforge () gnumonks org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
___________________________________________________________________________
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