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

1 files changed, 1 insertions, 1 deletions

diff --git a/sf-pcapng.h b/sf-pcapng.h
index d99b0d4e..835082a5 100644
--- a/sf-pcapng.h
+++ b/sf-pcapng.h
@@ -26,7 +26,7 @@
 #ifndef sf_pcapng_h
 #define	sf_pcapng_h
 
-extern pcap_t *pcap_ng_check_header(bpf_u_int32 magic, FILE *fp,
+extern pcap_t *pcap_ng_check_header(const uint8_t *magic, FILE *fp,
     u_int precision, char *errbuf, int *err);
 
 #endif