Repository navigation
Keep Inflater's remaining count exact when the output buffer is small - #64
Conversation
…emaining count stays exact
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 12 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
There was a problem hiding this comment.
The fix adjusts Inflate.run to return unconsumed whole bytes from the bit buffer on every call (not just at stream end), capping at the current call's consumed bytes. This matches zlib's behavior and keeps getRemaining exact when output buffers are small. The new test verifies exact stream consumption with output sizes 1–8 bytes.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict approve
What this changes
The faster inflate loop in #62 reads up to four input bytes ahead into its bit buffer. When a call stopped because the output was full, those bytes counted as read. At the end of the stream only bytes from the current call could be given back, so
Inflater.getRemaining()came out short when the output buffer was small.ZipInputStreamuses that count to find the data descriptor after an entry, so reading a deflated entry through a small buffer then failed on the next entry with "invalid entry size".java/util/zip/GZIP/GZIPInZip.javahits it with a 4-byteGZIPInputStreambuffer once the entries are really compressed.Each call now gives back the whole bytes left in the bit buffer, as zlib does, so input is consumed exactly up to the end of the stream.
Tests
test/zip.test.tsinflates a stream followed by extra bytes with output buffers of 1 to 8 bytes and checks that exactly the stream is read. It fails without the fix.pnpm typecheckandtest/zip.test.tspass.