Clarify that in a savefile the snapshot length indeed limits the maximum
packet size for both reading and writing, and that this is both the
intended and the implemented behaviour. See GiHub issue #215.
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
-.TH PCAP-SAVEFILE @MAN_FILE_FORMATS@ "6 Jan 2025"
+.TH PCAP-SAVEFILE @MAN_FILE_FORMATS@ "21 Jan 2025"
.SH NAME
pcap-savefile \- libpcap savefile format
.SH DESCRIPTION
.SH NAME
pcap-savefile \- libpcap savefile format
.SH DESCRIPTION
writers stored non-zero values in this field.
.IP
A 4-byte number giving the "snapshot length" of the capture; packets
writers stored non-zero values in this field.
.IP
A 4-byte number giving the "snapshot length" of the capture; packets
-longer than the snapshot length are truncated to the snapshot length, so
-that, if the snapshot length is
+longer than the snapshot length are truncated to the snapshot length.
+Specifically, when libpcap is writing to a savefile (from a live packet
+capture or otherwise), if the savefile's snapshot length is
+it writes to the savefile only the first
.I N
bytes of a packet longer than
.I N
.I N
bytes of a packet longer than
.I N
-bytes will be saved in the capture.
+bytes; when libpcap is reading from a savefile, it delivers at most
+.I N
+bytes for any packet in the savefile. Other software that needs to access
+savefiles directly should implement the same logic.
.IP
A 4-byte number giving the link-layer header type for packets in the
capture and optional additional information.
.IP
A 4-byte number giving the link-layer header type for packets in the
capture and optional additional information.