Tolerate GIFs missing the final trailer byte (0x3B)

[lilith]

Problem

A surprising number of real-world GIFs omit the final trailer block (0x3B). NB: This crate, if the encoder is not dropped before accessing the stream, also fails to emit the final trailer block. This is a consumer usage error but a light footgun I've personally run into. Browsers, ImageMagick, and PIL all decode them without complaint. Currently, after decoding every frame, the decoder hits EOF while looking for the next block introducer and surfaces UnexpectedEof — so a strict consumer (e.g. the image crate's collect path) rejects a fully-decodable GIF as corrupt.

Concrete repro

A real 67-frame GIF in the wild (example, 1.97 MB, 260×342) ends with 0x00 (the block terminator of its last image sub-block) and has no 0x3B trailer.

• gif 0.14.2 and current master: decode all 67 frames correctly (RGBA buffers match ImageMagick / PIL), then return Err(UnexpectedEof).
• ImageMagick and PIL both accept it (67 frames).

Fix

This relaxes only the clean-boundary case: when the decoder is between blocks — the previous frame fully completed and the next byte it expects is a block introducer/trailer — and at least one frame has been decoded, a trailing EOF is reported as a clean end-of-stream (Ok(None)) instead of an error.

Concretely, in ReadDecoder::decode_next, when fill_buf() returns empty:

if self.any_frame_decoded && self.decoder.is_at_block_boundary() {
    self.at_eof = true;
    break; // clean end-of-stream
}
return Err(DecodingError::UnexpectedEof);

is_at_block_boundary() is true only for the BlockStart(_) / BlockEnd states (waiting for the next block introducer). any_frame_decoded is set when a frame's Decoded::DataEnd is observed.

What still errors (zero-trust boundary)

• EOF in the middle of a frame (truncated image data / incomplete LZW sub-block / partial header) — genuine truncation → still UnexpectedEof / Truncated.
• EOF before any frame (zero-frames-then-EOF) — malformed → still errors.
• Any non-EOF error is unchanged.

This extends the same "accept non-terminated streams by cutting off when all bytes are decoded" philosophy noted in #235 to the missing-end-trailer case. It mirrors a guard we ship downstream.

Tests (tests/missing_trailer.rs)

• Positive: a valid two-frame GIF with the 0x3B trailer stripped decodes all frames cleanly, pixel-identical to the with-trailer decode.
• Negative (zero-trust): a GIF truncated mid-frame (frame 1 fully decodes, frame 2's data is cut) still errors — proving the relaxation doesn't open a truncation hole even after a complete frame.
• Negative: header-only / zero-frame-then-EOF still errors.

The full existing suite passes unchanged (trailer-present, truncation, stall/byte-at-a-time streaming).

Notes

• No public API change (is_at_block_boundary is pub(crate); any_frame_decoded is a private field).
• MSRV unchanged (1.85) — pure logic, no dependency change. Verified building + testing on 1.85.
• cargo fmt clean; clippy clean on the touched files.

[kornelski]

BlockStart means a block already started parsing, which is a bug here