Spotted in a profile that match_strval_ext() was calling
match_strval_linear() a lot (this value_string has 1476 entries - it was
epensive!).
Found error by adding temp debug to _match_strval_ext_init() - do we
ever expect the entries not to be in order? Am wondering if the warning
should be committed.
svn path=/trunk/; revision=44576
./Wireshark -v
wireshark 1.7.1 (SVN Rev Unknown from unknown)
Copyright 1998-2012 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 4.7.4 with GLib 2.30.0, with libpcap (version
unknown), with libz 1.2.3.4, with POSIX capabilities (Linux), with SMI 0.4.8,
with c-ares 1.7.4, with Lua 5.1, without Python, with GnuTLS 2.10.5, with Gcrypt
1.5.0, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 27
2011 11:52:20), without AirPcap.
Running on Linux 3.0.0-13-generic, with locale fr_FR.UTF-8, with libpcap version
1.1.1, with libz 1.2.3.4, GnuTLS 2.10.5, Gcrypt 1.5.0.
Built using gcc 4.6.1.
get_gui_compiled_info & get_gui_runtime_info copied from ../gtk/main.c
the function is common to GTK and Qt need to put in version_info.[ch] ?
svn path=/trunk/; revision=40691
Update of packet-e212.c dissector according to local national regulatory
MNC assignment document.
www.uke.gov.pl/uke/redir.jsp?place=galleryStats&id=24439
svn path=/trunk/; revision=35889
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4588#c6
2 and 3 digits long MNCs with the same arithmetic value (e.g.
21 and 021) are possible under the same MCC, yet in the
mcc_mnc_codes they would get mapped to the same entry. To
avoid this aliasing, the encoding of the MCC/MNC pair into a
single arithmetic value in the mcc_mnc_codes list is changed.
svn path=/trunk/; revision=32274
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
Since this leads to a compilation failure (Warning C4819: unexpected character
in the current code page) on non-european Windows, I'd like you to avoid using
non-ASCII characters in Wireshark code (even in comment).
svn path=/trunk/; revision=25214
Pascal Quantin