Wireshark-dev: Re: [Wireshark-dev] hfinfo.string const initializer / change VALS by preference
From: Harald Welte <laforge@xxxxxxxxxxxx>
Date: Sat, 19 Jun 2010 13:59:38 +0200
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@xxxxxxxxxxxx>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)