aboutsummaryrefslogtreecommitdiff
path: root/fmtutils.c
diff options
context:
space:
mode:
authorGuy Harris <guy@alum.mit.edu>2019-06-12 11:32:21 -0700
committerGuy Harris <guy@alum.mit.edu>2019-06-12 11:32:21 -0700
commit2e9d0ae34ece4d6f67f4d66a4c3628febf0b13dd (patch)
treec09a4191cd220422464f94b1806556d14307a2eb /fmtutils.c
parent978ccfe2193d270ad7e22ca0c7420b41e9de4f2c (diff)
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).
Diffstat (limited to 'fmtutils.c')
0 files changed, 0 insertions, 0 deletions