Using val_to_str seemed to be a good idea, but most value_string arrays were not properly filled or were using hacks.
(I hope I got everything right...)
svn path=/trunk/; revision=47218
must be filled in - even if we don't happen to have dissectors for
particular message types. Just put NULL in there, so we don't index
past the end of the array, grab a random location in memory's contents
as a function pointer, and crash when we call through that pointer.
svn path=/trunk/; revision=46747
- revert incorrect replacement of FALSE by ENC_BIG_ENDIAN
done a while back;
[The incorrect use of ENC_BIG_ENDIAN was benign since
ENC_BIG_ENDIAN is currently defined as 0x0000000];
svn path=/trunk/; revision=45651
Tried to provide consistency with GSM dissector (protocol) names, even if the filenames now don't match the dissector name.
svn path=/trunk/; revision=44162
(so idx won't be negative when used in the else statement). To avoid
this false positive, add a check if idx is negative to the if(str) check.
Also remove some trailing commas.
svn path=/trunk/; revision=41925
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
** (tshark.exe:4392): WARNING **: Dissector bug, protocol GSM BSSMAP, in packet
194520: More than 1000000 items in the tree -- possible infinite loop
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5688
svn path=/trunk/; revision=35939
packet-gtpv2.c:2648: warning: return type defaults to 'int'
packet-gtpv2.c: In function 'dissect_udp_s_port_nr':
packet-gtpv2.c:2690: warning: unused parameter 'length'
packet-gtpv2.c: In function 'dissect_gtpv2_fq_csid':
packet-gtpv2.c:2845: warning: unused parameter 'length'
packet-gtpv2.c: In function 'dissect_gtpv2_emlpp_pri':
packet-gtpv2.c:2927: warning: implicit declaration of function 'be_emlpp_prio'
packet-gtpv2.c: At top level:
packet-gtpv2.c:3056: warning: initialization from incompatible pointer type
svn path=/trunk/; revision=35431
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224