XEmacs and 1x1 gif images

[Robert Pluim]

On Sat, Dec 31, 2011 at 8:40 PM, Sean MacLennan <seanm at seanm.ca> wrote:
> On Sat, 31 Dec 2011 12:14:39 +0100
> Robert Pluim <rpluim at gmail.com> wrote:
>
>> Hi,
>>
>> ads.pheedo.com serves 1x1 gif images that are not 100% correct,
>> resulting in the following type of error when using gnus:
>
> It looks like the gif image is good... except it is missing the
> terminator byte (0x3b). It is such a HUGE gif, they are probably trying
> to save space ;)
>
>

:)

 All the readers I tried handled this gracefully, except XEmacs. Even
> Emacs handled it.
>
> I looked quickly at XEmacs 21.4 and DGifSlurp basically does this:
>
>  do {
>        GetRecordType
>
>        switch (type)
>                process
>
>  } while (RecordType != TERMINATE_RECORD_TYPE);
>
> Since there is no terminate byte, GetRecordType tries to read the next
> byte and fails.
>
> I have some gif knowledge, but I am no expert so take this with a
> lump of salt (unless you are on a salt reduced diet). But it looks like
> this is done to get around not keeping track of the gif version. So
> instead of doing what I would consider normal:
>
>  read header
>  if gif89a
>        read extension header
>  read image block header
>  read image blocks
>  read terminator
>
> XEmacs does this:
>
>  read header
>  Slurp (as shown above)
>
> It seems that the loop is only to handle the fact that the extension
> header may or may not exist.
>
> One solution is to check for EOF before calling GetRecordType, since it
> looks like the lack of a terminator is not considered fatal in practice.

In 21.5, we use an external giflib, so we'd have to move the guts of
Slurp into our codebase, with the modification you suggest. I'm not
sure how desirable that is.

Robert