Referring to this comment: I agree it's debatable, but the error message "unknown GIF code 0x..." is in a context (the main read loop) where only a few different codes are to be expected. I read the "grammar" in the GIF spec (Appendix B) and I believe that finding other codes in this place is a serious error, i.e. a broken GIF file. I'll double check this though.

In other places there's the notion of data (sub)blocks with a blocklen and a terminating block. If we encounter an "unknown GIF extension" we can (and do) skip and thus ignore the data blocks and continue reading. But that's definitely another issue.

BTW, we don't (yet) parse "empty" GIF files correctly. This one is from the pygif test suite mentioned here:

zero-height.gif: unknown GIF code 0x3b at offset 19
[229] Fl_GIF_Image: zero-height.gif - unexpected EOF or read error at offset 20

The point here is that 0x3b indicates the "trailer" (which we don't recognize). After that - I think - we should terminate the reader. This happens only if we don't find a valid image which means the Fl_GIF_Image object is empty (invalid). The GIF docs say in Appendix B:

The grammar indicates that it is possible for a GIF Data Stream to contain the Header, the Logical Screen Descriptor, a Global Color Table and the GIF Trailer. This special case is used to load a GIF decoder with a Global Color Table, in preparation for subsequent Data Streams without color tables at all.

Since we don't read "subsequent Data Streams" this is a moot point and we should exit gracefully - but I don't know yet what to do with the image object. Mark it as invalid (ERR_FORMAT) or create an image with w() = h() = d() = ld() = 0?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.