diff options
author | Simon McVittie <smcv@debian.org> | 2020-12-12 17:32:08 +0000 |
---|---|---|
committer | Simon McVittie <smcv@debian.org> | 2020-12-12 17:32:31 +0000 |
commit | bf13fc4c0d4ba9ced6015e825e58cde5370fe323 (patch) | |
tree | fc2ed31e85e0020c49e98e6b670f5943fafd9873 /po/sr@ije.po | |
parent | b7611c4bcb5e728db5dba63f46aa71e4473dc23e (diff) | |
download | gdk-pixbuf-bf13fc4c0d4ba9ced6015e825e58cde5370fe323.tar.gz |
gif: Do all of gif_init() with a single read
As documented in the introductory comment, the interface of the various
functions in the GIF loader is that they read all the bytes they need,
or return -1 if not enough are available. Since commit
5212d69f "gif: Replace old buffer management code with GByteArray",
the incremental loader strictly depends on that assumption.
Unfortunately, gif_init() didn't conform to that interface. If there
were enough bytes available for the GIF signature (GIF87a or GIF89a)
but not enough bytes for the screen descriptor, it would return -1
having already consumed the first 6 bytes of the stream. A subsequent
retry with more data available would start from the beginning of the
screen descriptor, and immediately raise an error because the screen
descriptor is extremely unlikely to start with another copy of the
"GIF8" magic number.
The regression test tests/pixbuf-short-gif-write.c would have detected
this, but was accidentally disabled by commit 7f0b214a "tests:
Conditionally build and run tests".
This seems most easily fixed by reading the whole of the 13-byte
fixed-length header in one go. Adjust the offsets into the buffer
used to parse the screen descriptor accordingly.
Signed-off-by: Simon McVittie <smcv@debian.org>
Diffstat (limited to 'po/sr@ije.po')
0 files changed, 0 insertions, 0 deletions