]> The Tcpdump Group git mirrors - libpcap/commit
Read the magic number into a byte array.
authorGuy Harris <[email protected]>
Wed, 12 Jun 2019 18:32:21 +0000 (11:32 -0700)
committerGuy Harris <[email protected]>
Wed, 12 Jun 2019 18:32:21 +0000 (11:32 -0700)
commit2e9d0ae34ece4d6f67f4d66a4c3628febf0b13dd
treec09a4191cd220422464f94b1806556d14307a2eb
parent978ccfe2193d270ad7e22ca0c7420b41e9de4f2c
Read the magic number into a byte array.

Apparently, in some C implementations, attempting to do an fread() into
a variable of a 32-bit unsigned integral type with a size of 1 and a
count of 4 returns 0 with an EOF indication; see GitHub pull request

We can make the size be the size of the variable and the count be 1, but
that means that the count returned by an fread() terminated by an EOF
will be 0, not the number of bytes successfully read, so the "truncated
dump file" message will give an invalid count:

tcpdump: truncated dump file; tried to read 4 file header bytes,
    only got 0

If, instead, we read into an array of 4 bytes, with a size of 1 and a
count of 4, we'll get the right short count back.

Pass the byte array to the file-type-specific "is this a file of this
type?" routines, so that if we add support for files where the magic
number isn't byte-order dependent (e.g., Microsoft Network Monitor), we
can handle them more cleanly (check for the standard magic number as a
4-byte array, rather than as its numerical value in both the host's byte
order and the byte-swapped byte order).
savefile.c
sf-pcap.c
sf-pcap.h
sf-pcapng.c
sf-pcapng.h