metaUtils: report uncompression failures to the caller

[hjmjohnson]

A truncated or corrupt compressed stream is read as a successful image. MET_PerformUncompression always returns true, and neither MetaImage nor MetaArray inspects the result.

Found while auditing MetaIO as vendored by ITK (InsightSoftwareConsortium/ITK#6575, items B65 and B66). New test testMeta14ImageCompressed covers both shapes and fails before this change.

The byte accounting had to be fixed first

MET_PerformUncompression ends in an unconditional return true; — every error path merely breaks out of the loop. The natural success criterion is "did we produce the expected number of bytes?", but dest_pos could not answer that:

err = inflate(&d_stream, Z_NO_FLUSH);
if (err == Z_STREAM_END || err < 0)
{
  ...
  break;                                             // <-- leaves before counting
}
uInt count_uncompressed = cur_remain_chunk - d_stream.avail_out;
dest_pos += count_uncompressed;

The output of the final inflate call — the one returning Z_STREAM_END — was never added, so a stream that decompressed in a single pass left dest_pos at 0. Counting each call's output before acting on its status makes dest_pos a true total, after which requiring dest_pos == uncompressedDataSize is a sound check. Both call sites now honour the result.

Compressed size absent from the header

When CompressedDataSize / CompressedElementDataSize is missing, the readers took the whole file as the payload:

_fstream->seekg(0, std::ios::end);
m_CompressedDataSize = _fstream->tellg();
_fstream->seekg(0, std::ios::beg);      // <-- start of the FILE

For a single-file (LOCAL) image the file begins with the ASCII header, so the header text itself was handed to inflate. Measuring from the current position — where the element data actually begins — is correct for both the LOCAL and separate-data-file cases, since the latter is already positioned at 0.

MetaArray::M_ReadElements carried the same assumption, and additionally never freed its compressed buffer; both are fixed here.

Testing

testMeta14ImageCompressed writes a compressed LOCAL image, strips CompressedDataSize from the header, and requires the data to read back correctly; then truncates the stream and requires the read to fail.

Verified fail-before/pass-after — before the change the first case reports element 1 is 0, expected 1, i.e. a silently zero-filled buffer returned as success. Full suite 13/13 passing.

Also run through ITK's MetaImageIO with no regressions in its Meta test suite.

[hjmjohnson]

@dzenanz Fixes before updating the ITK vendored copy two PR's pushed upstream:

MetaIO PRs are on Kitware/MetaIO:

• metaImage: validate LIST file dimension and slice count #141 — metaImage: validate LIST file dimension and slice count #141 — metaImage: validate LIST file dimension and slice count (B64: out-of-range LIST dimension + short slice list)
• metaUtils: report uncompression failures to the caller #142 — metaUtils: report uncompression failures to the caller #142 — metaUtils: report uncompression failures to the caller (B65 + B66: seek-from-file-start, unconditional return true, and the broken dest_pos accounting)

[dzenanz]

Consider addressing #143, to have a reliable test here before integrating into ITK/VTK.