The return value of pcap_dispatch() is described in pcap.3 as follows:
The number of packets read is returned.
Zero is returned when EOF is reached in a savefile.
A return of -1 indicates an error in which case ...
It will also return zero on the last short read (as "EOF is reached").
So if you read the packets in chunks of 100, like
while ((r = pcap_dispatch(src, 100, callback, NULL)) > 0) {
/* ... */
}
if (r == 0) {
/* EOF */
} else if (r == -1) {
/* ERROR */
}
and the file contains 120 packets, you will have
r == 100 the first time (reading 100 packets) and
r == 0 the second time (reading 20 packets).
It seems there is no way for the caller to know
how many packets were actually there in the last short read
besides counting the packets himself in the callback().
Is that intended? It seems more natural, and less surprising,
to have it return the actual number of packets. That would make
the sequence above 100, then 20, then 0 (like read(2) does).
Anyway, should this be explicitly mentioned in the manpage?
Jan
Index: pcap.3
===================================================================
RCS file: /cvs/src/lib/libpcap/pcap.3,v
retrieving revision 1.48
diff -u -p -r1.48 pcap.3
--- pcap.3 3 Jun 2018 10:45:15 -0000 1.48
+++ pcap.3 8 Dec 2018 12:53:59 -0000
@@ -345,7 +345,11 @@ and a
.Fa u_char
pointer to the packet data.
The number of packets read is returned.
-Zero is returned when EOF is reached in a savefile.
+Zero is returned when EOF is reached in a savefile;
+this includes a short read near the end of savefile,
+when less than
+.Fa cnt
+packets are available.
A return of \-1 indicates an error in which case
.Fn pcap_perror
or
