Please report BUGS to the current maintainer:
    Toshio Kuratomi <badger@prtr-13.ucsc.edu>

=======
Giflib assumes that there will be zero or one extension block per
image block.  Using more currently causes a corrupt image to be generated.
This needs to be fixed by allowing for more SaveImage->Functions to be saved
(ie: make it into an array rather than a simple int.  This seems like it
should also be moved into the Extension block structure rather than sitting up
a level in the SaveFile structure.)  However, this is problematic because it
breaks API and binary compatibility.

=======
From matan@arava.co.il  Fri Oct  2 12:01:51 1998
Date: Wed, 30 Sep 1998 15:48:15 +0200 (IST)
From: Matan Ziv-Av <matan@arava.co.il>
To: Toshio Kuratomi <badger@prtr-13.ucsc.edu>
Subject: A problem with libungif-3.1

I found two bugs in libungif-3.1:

1- when using DGifSlurp() on a file that contains extensions, the
library reads then and tries to store then in
GifFile->SavedImages->ExtensionBlocks,
but nowhere does it allocate memory for ExtensionBlocks.

[TEK][ I think I've fixed this.  Waiting for Matan to test it. ][TEK]

2- When DGifCloseFile()ing a file that at least one of its images has
a local colormap, Image.Colormap and SavedImages[i].ImageDesc.ColorMap
point to the same ColorMap (for some i), and so the lines

    if (GifFile->Image.ColorMap)
        FreeMapObject(GifFile->Image.ColorMap);
 
free this map and the lines 
    if (GifFile->SavedImages)
        FreeSavedImages(GifFile);
try to free it again, resulting in a segfault.

A fix for the scond problem might be not ot free Image.ColorMap if
there are SavedImages:

    if (GifFile->Image.ColorMap && !GifFile->SavedImages)
        FreeMapObject(GifFile->Image.ColorMap);

But I'm not sure if it does not cause other problems.

[TEK][ I think I fixed this by allocating two seperate colourmaps.  Waiting for
Matan to test this.][TEK]
