| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
