XEmacs and 1x1 gif images

[Robert Pluim]

On Mon, Jan 2, 2012 at 4:54 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Robert Pluim writes:
>  > On Sun, Jan 1, 2012 at 7:37 PM, Sean MacLennan <seanm at 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?)
>

I consider it a temporary local workaround, which we can discard now
I've discovered the appropriate Gnus variable. I don't think we should
install it.

> 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.
>

The thing is, the current code is sort-of doing the right thing: it's
signalling an error when the gif turns out to be invalid, it's just
that the end-result of that is 293 lines of backtrace.

If I could figure out a way to return something valid-but-empty from
gif_instantiate I would, but understanding is eluding me for now.

Also, having just tested this for other image types, the same problem
exists in at least {jpeg, png}_instantiate as well. Perhaps we should
catch that error in make-image-instance?

> 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. */
>
>

I'll make the unwind data non-local as see what happens, but I don't
have great hopes (but then again, I don't understand the code either
;) )

Robert