SeekableReader.truncate pads on the wrong side, the same family of defect as #604 but on a different path and with a complication that rules out the same fix.
Measured
On origin/main (a2be2cc1a), CPython 3.14.7, tree asserted as the repository's own:
r = SeekableReader(io.BytesIO(b'abcde'))
r.read(4) # b'abcd'
r.truncate(8)
r.seek(0)
r.read(8) # b'\x00\x00\x00e' <- expected b'abcd\x00\x00\x00\x00' or similar
Three things are wrong in that one line of output: the four octets already consumed are gone, the surviving e sits at the end rather than the start, and an 8-octet request returns 4 octets.
The padding site is pcapkit/corekit/io.py:328.
Why this is not a blind rjust → ljust swap
#604's fix in FieldBase.unpack is unconditional and safe because that code owns the whole buffer it pads. Here it is not, and the reason is concrete: io.BufferedReader's own C-level buffering is in play, so the visible content after a truncate depends on what the buffer has already absorbed and where its position sits. Changing the padding side without accounting for the buffer's state is as likely to move the corruption as remove it.
So this needs the buffer interaction worked out rather than a one-character change.
Why nothing catches it
tests/corekit/test_io.py:131-150 exercises truncate but only checks the return value, never the content. A padding-side defect is invisible to an assertion on the returned length.
That is the same shape as three other defects found in this repository today: a test that exercises the line without discriminating the behaviour. #603 was 100% branch coverage over a broken MP_JOIN path; #601's round-trip landed on a byte-aligned nonce; #618's len/cap_len inversion needed a truncated frame no fixture had.
Reachability
Not established. pcapkit/corekit/io.py:328's truncate had no callers at the time #593 examined the file, which is recorded in that PR's review. If that is still true this is latent rather than live — but the method is public on a public class, so a caller could reach it, and it behaves incorrectly when they do.
I have not re-checked the caller count; the claim above is from #593's review, not from my own grep.
Notes
SeekableReader.truncatepads on the wrong side, the same family of defect as #604 but on a different path and with a complication that rules out the same fix.Measured
On
origin/main(a2be2cc1a), CPython 3.14.7, tree asserted as the repository's own:Three things are wrong in that one line of output: the four octets already consumed are gone, the surviving
esits at the end rather than the start, and an 8-octet request returns 4 octets.The padding site is
pcapkit/corekit/io.py:328.Why this is not a blind
rjust→ljustswap#604's fix in
FieldBase.unpackis unconditional and safe because that code owns the whole buffer it pads. Here it is not, and the reason is concrete:io.BufferedReader's own C-level buffering is in play, so the visible content after atruncatedepends on what the buffer has already absorbed and where its position sits. Changing the padding side without accounting for the buffer's state is as likely to move the corruption as remove it.So this needs the buffer interaction worked out rather than a one-character change.
Why nothing catches it
tests/corekit/test_io.py:131-150exercisestruncatebut only checks the return value, never the content. A padding-side defect is invisible to an assertion on the returned length.That is the same shape as three other defects found in this repository today: a test that exercises the line without discriminating the behaviour. #603 was 100% branch coverage over a broken MP_JOIN path; #601's round-trip landed on a byte-aligned nonce; #618's
len/cap_leninversion needed a truncated frame no fixture had.Reachability
Not established.
pcapkit/corekit/io.py:328'struncatehad no callers at the time #593 examined the file, which is recorded in that PR's review. If that is still true this is latent rather than live — but the method is public on a public class, so a caller could reach it, and it behaves incorrectly when they do.I have not re-checked the caller count; the claim above is from #593's review, not from my own grep.
Notes
FieldBase.unpack's padding side, and reported rather than folded in — correctly, since the buffer complication makes it a different piece of work from a one-character change.pcapkit.__file__asserted against the repository tree rather than relying on the editable install, which on this machine resolves to a checkout fourteen commits behindorigin/main.FieldBase.unpack, fixed in fix(corekit): pad a short field read on the tail, not the head (#604) #621), OptionField.unpack never returns for a well-formed HOPOPT header with an SMF_DPD option #431 (the short-read accommodation the family rests on).