routines and routines using those routines. GLib might use different
modifiers for 64-bit quantities than the platform's C library does.
svn path=/trunk/; revision=21990
--enable-extra-gcc-checks set.
If we turn on -pedantic, try turning on -Wno-long-long as well, so that
it's not *so* pedantic that it rejects the 64-bit integral data types
that we explicitly require.
Constify a bunch of stuff, and make some other changes, to get rid of
warnings.
Clean up some indentation.
svn path=/trunk/; revision=21526
Attached is a wireshark patch that adds support for decoding DHCP option 125
and the DHCP option 125 suboptions defined by the DSL Forum's TR-111
specification.
svn path=/trunk/; revision=20783
- allow DHCP option 43 suboption 8 (OUI) for CableLabs clients to be a 6-byte string (as required for DOCSIS CMs) to
account for inconsistencies in different CableLabs specifications
- add new DHCP option 60 fields 0x0d (IP Filters Support) and 0x0e (LLC Filters Support) for CableLabs DOCSIS 2.0 CMs
- rename PKT_CM_* variables to have a DOCS_CM prefix instead (overdue, as indicated by an existing comment)
- update specification references
svn path=/trunk/; revision=17884
- Display UUID for tag #97 (Client machine identifier)
- Display UNDI major and minor version for tag #94 (Client network
interface identifier)
- Use value strings for tag #93 (Client system architecture)
The byte ordering is messed up for the GUID though.
svn path=/trunk/; revision=17541
packet-ntp.c: Rather confused and incorrect use of g_snprintf return value
packet-pim.c: whitespace change
packet-icmpv6.c: g_snprintf takes trailing \0 into account, fix off by 1 error
packet-clnp.c: Fix incorrect use of g_snprintf return value
packet-isakmp.c: g_snprintf takes trailing \0 into account
packet-tr.c: Fix incorrect use of g_snprintf return value
packet-radius.c: Fix incorrect use of g_snprintf return value
packet-radius.h: constify a string variable
packet-ldap.c: The return value isn't needed, so don't use it incorrectly
packet-tcp.c: Fix incorrect use of g_snprintf return value
packet-windows-common.c: Remove unneeded DISSECTOR_ASSERT
packet-smb-sidsnooping.c: g_snprintf takes trailing \0 into account
packet-pvfs2.c: g_snprintf takes trailing \0 into account
packet-ptp.c: Remove #include snprintf
packet-ppp.c: Fix incorrect use of g_snprintf return value
packet-ospf.c: Fix incorrect use of g_snprintf return value
packet-mip6.c: snprintf -> g_snprintf
packet-bootp.c: Remove a commented out bad use of g_snprintf
packet-ber.c: snprintf -> g_snprintf, g_snprintf takes trailing \0 into account
2do:
52 packet-ieee80211.c: 2DO
2 packet-nfs.c: 2DO - too many side effects
33 packet-bgp.c: 2DO
18 packet-dns.c: 2DO
14 packet-dcm.c: 2DO
13 packet-x11.c: 2DO
11 packet-kerberos.c: 2DO
10 packet-diameter.c: 2DO
9 packet-snmp.c: 2DO
9 packet-pgm.c: 2DO
7 packet-nbns.c: 2DO
6 packet-fcswils.c: 2DO
5 packet-wccp.c: 2DO
5 packet-cops.c: 2DO
4 packet-wtp.c: 2DO
svn path=/trunk/; revision=17038
also change one (of several:-( ) arrays to be accessed through accessor functions so proper bounds checking is done.
there are many other inbstances of arrays in this dissector that are accessed with no proper bounds checking and the same thing should be done for them
svn path=/trunk/; revision=16891
calls to "tvb_get_ipv4()" and "tvb_get_ipv6()".
Fix a call in the BGP dissector to properly fetch an IEEE floating-point
number.
Update some I-D info.
svn path=/trunk/; revision=15774
and that extract IPv6 addresses into a "struct e_in6_addr", with
tvb_get_ipv4() and tvb_get_ipv6() calls - except for some that we
remove, by using proto_tree_add_item(), rather than replacing.
Have epan/tvbuff.h include epan/ipv6-utils.h, to define "struct
e_in6_addr" (not necessary to declare the tvbuff routines, but including
it there means "struct e_in6_addr" is guaranteed to be defined before
those declarations, so we don't get compiler complaints if we define it
*after* those declarations).
svn path=/trunk/; revision=15758
Make sure the delta is > 0.
This intends to fix bug 160, although with a capture file
to test it, I can't be totally sure.
svn path=/trunk/; revision=14322
whether the suboption data offset plus the suboption data length is >,
not >=, the end of the option data - the end of the option data is the
first byte *after* the option data.
For CableLabs string suboptions, use the right offset when fetching the
data.
svn path=/trunk/; revision=13884
Guy Harris