No really, it reads 20 packets and returns zero.
On Dec 08 13:56:09, h...@stare.cz wrote:
> 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
>
