[moberg]

Malformed PDFs whose content stream never reaches a closing ']' previously drove (*buffer).readArray into an infinite loop: readToken returns io.EOF, the loop unreads it, calls readObject, which returns the same io.EOF, and the array slice grows by one element per iteration. On some inputs this allocates many GB before the process is OOM-killed.

readDict already has the same io.EOF guard. This change adds the matching guard to readArray.

Reproduced and validated with a content-stream-truncated PDF that previously hung at >30 GB resident memory; with the fix the parse returns cleanly within milliseconds.

[ledongthuc]

@moberg The fix in this PR already exists in master. Commit 601f614 ("lex: stop readArray looping forever on io.EOF") adds the same check.

The condition in readArray is now:
if tok == nil || tok == io.EOF || tok == keyword("]") { break }

This means the new block in this PR is not run. The io.EOF check in this PR can never be true at that point.

So I will close this PR. But if you have any comment, feel free to add.