Robert Pluim writes:
On Sun, Jan 1, 2012 at 7:37 PM, Sean MacLennan <seanm(a)seanm.ca>
wrote:
> static int
> gif_read_from_memory (GifFileType *gif, GifByteType *buf, int size)
> {
> gif_memory_storage *mem = (gif_memory_storage *) gif->UserData;
>
> if (size > (mem->len - mem->index)) {
> /* Hack to handle a gif file that is missing the terminator byte. */
> if (size == 1 && mem->len > 1 && mem->bytes[mem->len
- 1] != 0x3b) {
> *buf = 0x3b;
> mem->len = 0;
> return 1;
> } else
> return -1;
> }
> memcpy (buf, mem->bytes + mem->index, size);
> mem->index = mem->index + size;
> return size;
> }
It works for me, I'll run with it installed for a while and see
if it
causes any problem (I'd be surprised if it did).
Are you guys seriously proposing that we special-case this one
particular bogus file? By simply silently ignoring the error?
(AFAICS the statement "mem->len = 0;" tells giflib that there's no
data there, no?)
We really need to fix the error stuff that Robert mentioned (which
should give the same result, or perhaps the calling code will need to
do a condition-case to ignore the GIF error). Presumably that could
happen on a real corrupted GIF.
I wonder if this comment at the top of gif_instantiate() might not
have something to do with it:
/* It is OK for the unwind data to be local to this function,
because the unwind-protect is always executed when this
stack frame is still valid. */
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta