[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Changelog entry: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• fix — a bug fix

---

Description of your pull request and other information

A declared length above sys.maxsize, such as a PCAP incl_len of 2**31 - 16 on GraalPy or 32-bit CPython, used to crash a read or seek with OverflowError before the overrun handling could see it. Every length-driven read is now bounded at sys.maxsize, so a hostile claim comes back short and gets the same "captured length runs past the data" or "block truncated" handling as on 64-bit CPython. Claims that fit are read exactly as before.

• Schema.unpack: the payload and field reads. These cover PCAP payloads, PCAP-NG nested fields and the next layer's cap_len.
• Frame.read: the record read, and the next-record offset when it lies past sys.maxsize.
• PCAPNG.read and _read_block_cut: the block reads.
• SeekableReader._fill: a READ_CHUNK of -1.
• fix(corekit): copy SeekableReader's octets and feed MultiDict a dict, and gate GraalPy's limits (#1963) #1974's sys.maxsize skips in the two fix(dumpkit): a PCAP trace copies a truncated record's claimed incl_len, writing a malformed file #1541 modules are removed.

The new test_declared_length_past_maxsize_1975_unit.py (ALL) simulates a 32-bit Py_ssize_t on CPython. It fails on main (12 failed) and passes here. On GraalPy 25.4.4, the two #1541 modules and the new one pass with no skips, while main fails 14 with OverflowError. The third-party engines are left as they are, as best effort under #1687.

Closes #1975

[JarryShaw]

When the desired read is beyond sys.maxsize or sys.maxint, should'nt we make multiple reads to satisfy the request instead of cutting short and bounding at the limit?

[JarryShaw]

Partly yes. I measured on GraalPy 25.4.4, where sys.maxsize is 2**31−1:

• A single read above sys.maxsize raises OverflowError, and so does bytes(2**31). No object can hold more than sys.maxsize octets, so several reads could not be joined into one payload on these builds. Bounding the payload read is unavoidable.
• A seek past sys.maxsize works, both absolute and relative.

The PR gets the second part wrong. When a record's next offset lies past sys.maxsize, Frame.read falls back to the end of the octets it read. On a file that really holds such a record, that misaligns every later record. So I'll change it to keep the payload bounded (with the truncation warning) but advance the stream to the declared end of the record:

• by relative seeks when the stream is seekable;
• by chunked read-and-discard when it isn't.

The PCAP-NG block reads get the same treatment. Later records then parse exactly as they do on 64-bit CPython.

[JarryShaw]

Pushed 9e0c3719d. A record or block that really extends past sys.maxsize is now moved past whole, so the next one parses at its declared offset. The payload stays bounded and warned.

• A new pcapkit.corekit.io.advance moves by relative seeks, or by chunked read-and-discard on a SeekableReader or a pipe.
• Frame.read and PCAPNG.read call it.
• On the pipe path, the pcap/pcapng engines' _bound_read_ahead, the PCAP frame schema's packet length and SeekableReader._fill are also bounded at sys.maxsize.
• A file shorter than its claim behaves as before.

The new sparse-stream tests fail on 0fd43fb67 (5 failed) and pass here. They run seekable, through a pipe, and with READ_CHUNK=-1. GraalPy 25.4.4 passes 16. A delta review is running.

[JarryShaw]

GOOD TO GO at 9e0c3719d. A Sonnet delta review probed advance across BytesIO, SeekableReader, and pipes with zero, negative, exact and past-EOF counts. It found that advance only runs when a read came back whole but the declared length is longer, so 64-bit behaviour is unchanged. The sparse-stream tests check the next record's content. The PR also passes merged with #1983 and main. Open point: advance has only one internal caller. Should it stay public in pcapkit.corekit.io, or become _advance? Non-blocking: for a record that really extends past the limit, the kept 'runs past the data' warning is misleading.

[github-actions]

Coverage: 91.52% (unit tier, Python 3.15, 9e0c3719d, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	2	95.16%
pcapkit/const	19597	881	2618	867	92.11%
pcapkit/corekit	2540	71	808	37	96.54%
pcapkit/dumpkit	276	3	100	3	98.40%
pcapkit/foundation	2918	23	1016	25	98.78%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	17423	224	4586	189	98.11%
pcapkit/toolkit	872	36	298	10	95.21%
pcapkit/utilities	522	2	158	4	99.12%
pcapkit/vendor	4431	1995	1018	167	51.73%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

use advance

[JarryShaw]

Keeping advance public, as you said. No change needed.