summaryrefslogtreecommitdiff
path: root/tests
diff options
context:
space:
mode:
authorSimon McVittie <smcv@debian.org>2020-12-12 17:32:08 +0000
committerSimon McVittie <smcv@debian.org>2020-12-12 17:32:31 +0000
commitbf13fc4c0d4ba9ced6015e825e58cde5370fe323 (patch)
treefc2ed31e85e0020c49e98e6b670f5943fafd9873 /tests
parentb7611c4bcb5e728db5dba63f46aa71e4473dc23e (diff)
downloadgdk-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 'tests')
0 files changed, 0 insertions, 0 deletions