hfinfo.string const initializer / change VALS by preference ?

[Harald Welte <laforge () gnumonks org>]

Hi!

As part of the OpenBSC project, I've been  working on a dissector for the GSM
A-bis OML protocol.  One of the problems with this protocol is that it only
specifies a set of common functions which are then extended by each
vendor/implementor.

This starts with the message type.  There are some message types that are
according to the GSM TS 12.21, and then there are vendor-specific message
types.  The ranges of the vendor-specific message types overlap.

so let's say the spec has defined 0x01, 0x02, 0x03 and vendor A uses 0x05,
0x06, whereas vendor B uses 0x05 and 0x06 for something completely else.

Thus, it is impossible to make one 'value_string' array that encompasses
all the message types and their names.

Luckily, I can have a preference that allows the user to select which vendor
his trace uses.

My idea was to use the proto_handoff() function to check the preference and
then dynamically allocate (and populate) a value_string[] array that contains
the combination of the standard message types as well as the specific message
types for the preferences-selected vendor.

However, this fails since the hinfo.strings value needs toe have a constant
initializer.  And as hfinfo is registered in the proto_register() function,
there is probably no way for me to change this from within proto_handoff()

What is the preferred method to solve this kind of problem?  I'm sure the
issue of conflicting vendor-specific extensions must have occurred in other
protocols, too.

Any help is appreciated.

[p.s.: Once the dissector is finished, it will of course be submitted!]

-- 
- 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