PLMN 440 20 is now used by SoftBank.
While we are at it, update the E.212 list to the latest operational bulletin no. 1041.
svn path=/trunk/; revision=54496
1. Case sensitivity differences between hf_ field name and formatted string.
2. Unnecessary whitespace between hf_ field name and colon in formatted string
There are cases where the hf_ field name doesn't quite match the proto_tree_add_uint_format, but it's close enough that one of them should be "right", I'm just not sure which is, I just know the string in proto_tree_add_uint_format is the one displayed.
svn path=/trunk/; revision=52098
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
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