That makes it clearer which captures are pcap and which are pcapng, and
could allow us to, if we're testing with a tcpdump linked with a libpcap
that doesn't handle pcapng files, skip the pcapng files.
tcpdump doesn't care (the upper 16 bits of the link-layer header type
field in pcap frames is sort-of reserved for extensions - libpcap
separates it from the link-layer header type, and tcpdump doesn't look
at the extensions), but Wireshark does.
It was, its name nonwithstanding, a pcapng file, and had an SHB option
that was damaged by fuzzing. Converting it to pcap
1) means it has the appropriate extension;
2) means that old libpcaps that can't read pcapng can handle it;
3) means that a future libpcap that fully supports pcapng *and* thus
fails on that file can handle it.
First, check whether the originate timestamp is greater than the other
timestamp and, if so, calculate (originate - other) and print a -
instead of a + before it. This means we're not trying to stuff the
difference between two unsigned values into a signed value of the same
width (the result of which is undefined if the difference doesn't fit in
the signed variable).
That also means we do one less decrement, so it's not as if testing
i-- rather than testing i and separately decrementing it is an
optimization.
Fix some types to unsigned while we're at it - and do the above change
for them, too.
In fact, don't waste time incrementing the pointer or decrementing the
count until we know that we're going to go through another trip through
the loop. (This isn't a PDP-11 and probably isn't a VAX or 68k, so *p++
isn't going to be done by an addressing mode.)
This should fix an undefined-behavior warning.
In RFC 6126 TLV type 9 is "Route Request", TLV type 10 is "Seqno
Request" and the field in the IHU TLV is called "Rxcost". Make the
decoder spell those data items the same way. Add some comments and
update tests.
This ensures that we have no purportedly-aligned-but-not-necessarily-
unaligned values that we access; we have to use EXTRACT_ macros/functions
to get at IPv4 address values.
In 'struct icmp'.
This avoid some 'undefined-behavior' warnings with clang and option
-fsanitize=undefined enabled.
Moreover:
Remove unneeded '&' when getting a pointer to a nd_ipv4 type.
Fix indentation.
The warnings were like:
print-icmp.c:355:2: runtime error: member access within misaligned address
0x61d00001eabe for type 'const struct icmp', which requires 4 byte alignment
0x61d00001eabe: note: pointer points here
ef 01 02 03 08 00 90 e1 00 03 00 00 00 00 00 00 00 05 ed 60 ab cd ab cd ab cd ab cd ab cd ab cd
^
SUMMARY: AddressSanitizer: undefined-behavior print-icmp.c:355:2 in
In 'struct hsrp'.
This avoid some 'undefined-behavior' warnings with clang and option
-fsanitize=undefined enabled.
Moreover:
Remove unneeded '&' when getting a pointer to a nd_ipv4 type.
The warnings were like:
print-hsrp.c:102:2: runtime error: member access within misaligned address
0x61d00001eaaa for type 'const struct hsrp', which requires 4 byte alignment
0x61d00001eaaa: note: pointer points here
00 1c 2d 8d 00 00 10 03 0a 64 01 00 63 69 73 63 6f 00 00 00 c0 a8 00 01 be be be be be be be be
^
SUMMARY: AddressSanitizer: undefined-behavior print-hsrp.c:102:2 in
Include <stdio.h> on Digital/Tru64 UNIX to get snprintf(); we assume the
versions on which people will build this (if any) will have it. (1998
called, they want their C library back....)
Some versions of the MSVC runtime library have a non-C99-compliant
vsnprintf(), which we want to avoid. On Windows, use snprintf() and
vsnprintf() for VS 2015 and later, where they both exist in
C99-compliant forms, and wrap _{v}snprintf_s() otherwise (they're
guaranteed to do the null termination that we want).
They don't behave exactly like ISO C {v}snprintf(), so, on Windows, we
have wrappers around _{v}snprintf() that behave the way {v}snprintf()
are supposed to work.
Now that we're using check_symbol_exists(), CMake can find it, so we
don't need to check the compiler version - and this avoids a warning
about redefining HAVE_SNPRINTF.
