FlateDecode: a stored first block begins with NUL, which is white-space

[tannevaled]

flateDecode skips leading white-space before inflating, because producers put the stream's EOL there. NUL is one of the six bytes the specification calls white-space — isSpace says so, correctly — and a bare deflate stream whose first block is stored begins with a NUL. So the skip ate a real byte.

The failure was silent. Take 00 03 00 fc ff "abc", a stored block holding abc. Drop its NUL and the remainder reads as a fixed-Huffman final block that ends immediately:

	result
before	"", no error
after	"abc"

An empty stream and a clean bill of health. That is worse than an error, because nothing downstream can tell it from a stream that really was empty.

Stored blocks are not a corner case. They are what a deflater emits for data that will not compress — in a PDF, every image that arrived already compressed.

The fix

Where the data begins is genuinely ambiguous, so it is now settled by reading rather than by guessing: every split point inside the leading white-space run is tried, and the read that actually yields bytes wins.

No single rule can do it. "\r\n" before a stored block needs exactly two bytes skipped, not three; a bare stored block needs zero. Both cases are in the tests.

zlib is still tried only past the white-space, and that is provable rather than assumed: RFC 1950 fixes CM to 8, so the low nibble of a zlib stream's first byte is 8, and none of 00 09 0a 0c 0d 20 has a low nibble of 8. A valid zlib stream cannot begin inside a white-space run.

The second failure

TestDecodeRecoveringDamagedFlateKeepsPredictor asserted the recovered bytes were a prefix of the undamaged output. That only ever held because the halfway cut fell on a row boundary.

pngPredictor deliberately keeps a truncated final row, zero-filled — TestPNGPredictorTruncatedRow pins exactly that, and its comment says so. A row rebuilt from bytes that are not there cannot be a prefix of anything. The assertion now covers the whole rows and excludes the one the damage landed in.

Measured: the truncated stream inflates to 627 bytes = 125 whole 5-byte rows plus 2 bytes, and the divergence was at byte 501 — the 126th row. Exactly the partial one.

How it surfaced

Go 1.27's deflater stores this test's data where 1.26 compressed it — 45 bytes starting 2a ce cf 4d became 46 starting 00 27 00 d8. The library was wrong before that; nothing about it changed. This is what go-pdfkit/reader#22 has been failing on.

Verified

• full suite green under go1.26.4 and go1.27.0
• 100.0% of statements under both, which the repo's exact gate requires
• go vet clean; gofmt clean under both toolchains
• new tests: a hand-built stored block starting with NUL, and a raw deflate stream behind a \r\n. Both are built by hand rather than by a deflater, because which block type a deflater picks is its own business and moves between releases — which is the whole lesson here.