[print-forces.c:316] -> [print-forces.c:323]: (warning) Shifting 32-bit
value by 32767 bits is undefined behaviour. See condition at line 323.
[print-forces.c:316]: (error) Shifting by a negative value is undefined
behaviour
When compiled with the Solaris Studio 12.3 compiler (as in the OpenCSW
buildbot system at the time), tcpdump passed all the tests. When
compiled with GCC 5.2.0 on the same host, the following tests failed
because tcpdump terminated with SIGILL (Bus Error - core dumped):
icmpv6, icmpv6_opt24-v, dhcpv6-aftr-name, dhcpv6-ia-na, dhcpv6-ia-pd,
dhcpv6-ia-ta, dhcpv6-ntp-server, dhcpv6-sip-server-d,
dhcpv6-domain-list, kday1. This change fixes the issue with the method
suggested in commit 1376682.
The purpose of this macro was to enable the file-by-file switch to NDO,
after which only tcpdump.c had a use of it and the definitions guarded
by it. Update tcpdump.c not to require them any more and dismiss the
unused definitions.
As section 7 of RFC 5810 says, an OPER-TLV is 1*PATH-DATA-TLV, so it
always has at least one PATH-DATA-TLV. Remove the ZERO_TTLV check - the
old one was bogus ((!ops->flags & ZERO_TTLV) means ((!ops->flags) &
ZERO_TTLV), and if ops->flags is non-zero, !ops->flags is zero, and the
test fails), and the new one causes tests to fail, revealing that the
whole "empty TLVs like COMMIT and TRCOMMIT are empty, we stop here"
think is wrong, so we remove it.
If that flag is set, the TLV in question is empty, so don't process
anything further - and if it's *not* empty, report an error.
Thanks to Maks Naumov for finding this.
And, as we require at least autoconf 2.61, and as autoconf 2.61 and
later have AC_TYPE_UINTn_T and AC_TYPE_INTn_T macros, we use them to
define the uintN_t and intN_t macros if the system doesn't define them
for us.
This lets us get rid of bitypes.h as well.
This time eliminate a few instances of the code initializing struct tok
with negative values and squelch the warnings like below:
warning: initializer will be sign-extended: -1
For each decoder that has more than one instance of truncation signaling
and prints the same string in each instance make sure that the string is
declared as "static const char tstr[]" right after the initial includes
block. Where necessary, replace fputs(s, stdout) with equivalent
printf("%s", s).
Make sure all of them are declared const and most of them -- static.
Proper declaration of token arrays is a common review point for new code
that is based on existing decoders. Thus fix the issue at its root.
Do *NOT* assume that "%l[doxu]x" - or "%ll[doxu]" - is the way to print
a 64-bit quantity; on UN*X, it might be a "long" or a "long long",
depending on whether you're on a 32-bit or 64-bit platform and, on
Windows with MSVC++, it's not a long (even in 64-bit mode) and doesn't
use "%ll[doxu]", either. Instead, use PRI[doxu]64; that's what C99
defines, and what we define ourselves if the C environment doesn't
define it.
In some loops, don't loop just until we get an error, stop when we run
out of data to parse.
Also, add some comments to indicate what we know about lengths at
various points, before we do something with the length that happens to
assume what we know. Add some checks that this auditing found
necessary.
Use ForCES_HDRL, TLV_HDRL, and ILV_HDRL instead of various sizeof's, to
make it clearer what certain tests ensure are true (as, in other cases,
the #defines are subtracted from values that should be, at that point,
ensured not to be less than the #define in question).
Add TCHECK/TCHECK2 calls to make sure we are within the packet boundary
before fetching data. Make some length variables that could in theory
have values that don't fit in 16 bits 32 bits long.
Get rid of blanks before newlines.
Use EXTRACT_16BITS() and EXTRACT_32BITS() to fetch 16-bit and 32-bit
big-endian quantities from the packet, as there's no guarantee that a
given 16-bit quantity will be aligned on a 2-byte boundary or that a
given 32-bit quantity will be aligned on a 4-byte boundary, nor is there
a guarantee that unaligned accesses will succeed (they might trap, or
they might not fetch an unaligned quantity).
