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: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
