metaUtils: consume the trailer when the output buffer fills first

[hjmjohnson]

Fixes a regression I introduced in #145: MET_PerformUncompression rejects valid compressed data when the gzip trailer lands in a different input chunk than the last data byte.

Reported by an automated review on the ITK side (InsightSoftwareConsortium/ITK#6835), where #145 arrived via the MetaIO sync.

Root cause

The decompression loop feeds input in MET_MaxChunkSize (1 GiB) pieces. When the output buffer is exactly full and the chunk boundary falls inside the 8-byte trailer, the next inflate call has no output capacity and returns Z_BUF_ERROR. The outer loop

} while (err != Z_STREAM_END && err >= 0);

treats that as terminal even though input remains, so the trailer is never consumed. The Z_STREAM_END requirement added in #145 then rejects a payload that was fully and correctly decompressed.

The inner loop already documents this return as benign:

if (err != Z_STREAM_END && err != Z_BUF_ERROR) // Z_BUF_ERROR means there is still data to uncompress,
{                                              // but no space left in buffer; non-fatal

so the post-loop check contradicted a comment three lines above it. The underlying loop behavior predates #145; requiring Z_STREAM_END only made it observable.

The fix, and why not simply drop the check

zlib validates the CRC32 trailer only at stream end, so removing the requirement would restore a hole where a payload with a corrupt trailer is accepted whenever the byte count happens to match — the dest_pos != uncompressedDataSize test catches truncation but not corruption.

Instead, keep feeding the remaining input into a one-byte scratch output until zlib reports Z_STREAM_END or a genuine error. Valid deferred-trailer streams are accepted; corrupt and truncated ones are still rejected.

Verification

The trigger is narrow: crossing the 1 GiB boundary is not sufficient, since inflate returns Z_STREAM_END at an exactly-full output buffer as long as the trailer is in the same input chunk. A 1216502568-byte stream was accepted unchanged. The boundary must fall inside the trailer.

Binary-searching the raw size produced that alignment — raw=1018073420, compressed=1073741829, five trailer bytes in the second chunk:

Case	before	after
Trailer split across the chunk boundary	rejected, zlib error -5 (content correct)	accepted, content matches
Clean stream	accepted	accepted
Corrupt CRC trailer	rejected	rejected (-3)
Truncated stream	rejected	rejected (-5)

Behavior was exercised against a build of this function in ITK (which vendors zlib-ng); this branch also compiles clean in a standalone MetaIO build.

[dzenanz]

Looks good on a glance.

[hjmjohnson]

@dzenanz would you review and merge this one? I don't have merge rights here.

CI note: the red CircleCI check is pre-existing and unrelated to this change. GitHub Actions (Ubuntu 24.04), which builds and runs the suite, passes.

Evidence that CircleCI is failing project-wide

Every recent master build fails the same way:

build	branch	outcome
275	pull/148	success
274	pull/147 (this)	failed
273	master	failed
272	pull/146	failed
271	master	failed
269	master	failed
267	master	failed
265	pull/141	failed

The step breakdown is identical on master and here:

'Spin up environment':             success
'Preparing environment variables': success
'Checkout code':                   success
'/usr/src/MetaIO/test/ci/test.sh': canceled

The job reports failed_reason: None and the step is canceled rather than failed, which points at the Docker-based test/ci/test.sh timing out or being unable to start — not at a test result. Worth a separate look at some point; it currently shows red on every PR the project receives.

Companion PR #148 adds a regression test for this defect. It depends on this one — please merge this first, then I will rebase #148 on top of it.