How about the following workaround? Please note that I do not have access
to a Windows development environment, but this patch has been tested
on a Fedora 7 Linux host.
pika.localdomain:~/mobileMetrics/wireshark/svnWork/latest 0:22> svn diff
Index: plugins/wimaxasncp/packet-wimaxasncp.c
===================================================================
--- plugins/wimaxasncp/packet-wimaxasncp.c (revision 22816)
+++ plugins/wimaxasncp/packet-wimaxasncp.c (working copy)
@@ -2916,6 +2916,7 @@
proto_tree *vsif_tree;
proto_item *item;
guint32 vendorId;
+ const gchar *s;
item = proto_tree_add_text(
tree, tvb, offset, length,
@@ -2931,14 +2932,14 @@
vendorId = tvb_get_ntoh24(tvb, offset);
- proto_tree_add_uint(
+ s = val_to_str(vendorId, sminmpec_values, "Unknown");
+
+ proto_tree_add_uint_format(
vsif_tree, hf_wimaxasncp_tlv_value_vendor_id,
- tvb, offset, 3, vendorId);
+ tvb, offset, 3, vendorId,
+ "Vendor ID: %s (%u)", s, vendorId);
- proto_item_append_text(
- tlv_item,
- " - %s",
- val_to_str(vendorId, sminmpec_values, "Unknown"));
+ proto_item_append_text(tlv_item, " - %s", s);
offset += 3;
@@ -4148,7 +4149,7 @@
"wimaxasncp.tlv_value_vendor_id",
FT_UINT24,
BASE_DEC,
- VALS(sminmpec_values),
+ NULL,
0x0,
"",
HFILL
--
Steve Croll
Anders Broman wrote:
> Hi,
> The code at line 2934:
> proto_tree_add_uint(
> vsif_tree, hf_wimaxasncp_tlv_value_vendor_id,
> tvb, offset, 3, vendorId);
>
> proto_item_append_text(
> tlv_item,
> " - %s",
> val_to_str(vendorId, sminmpec_values, "Unknown"));
>
> Suggests that this problem was seen before so a workaround exists.
> Regards
> Anders
>
>
> -----Ursprungligt meddelande-----
> Från: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] För Guy Harris
> Skickat: den 6 september 2007 20:36
> Till: Developer support list for Wireshark
> Ämne: Re: [Wireshark-dev] WiMAX ASN Control Protocol dissector submission
> status?
>
> Martin Mathieson wrote:
>
>> I checked this in earlier today, but have the following remaining
>> Windows warning/error.
>>
>> packet-wimaxasncp.c(4151) : error C2099: initializer is not a constant
>>
>
> This has happened before:
>
> http://www.wireshark.org/lists/wireshark-dev/200702/msg00500.html
>
> but I didn't see anything in the thread that came to a conclusion; my
> suspicion:
>
> http://www.wireshark.org/lists/wireshark-dev/200702/msg00505.html
>
> is that "Windows' run-time linker (or whatever the code that implements
> DLLs at run time is called) can't resolve a data reference from a
> run-time-loaded DLL (a plugin) to a data item from a DLL loaded as a
> library, so that the compiler can't generate code with the appropriate
> relocation information for that item", but "I'm not enough of an expert
> on Windows' run-time linker to say whether that's the case or not".
>
> Does anybody out there know whether a DLL can import a data item from
> another DLL? (Not an application importing data from a DLL, and not a
> DLL using data from itself, and not a DLL importing a data item from the
> application itself - a run-time-loaded DLL picking up a data item from a
> startup-time-loaded DLL with which the run-time-loaded DLL could be linked.)
>
> It's certainly possible with the dynamic linking mechanisms used in
> various UN*Xes; is it possible in Windows?
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
