Edit utils to get rid of use of all deprecated Functions.
- icon2gif has MakeExtension

Check how the library uses MakeExtension and AddExtensionBlock.  I have the
vague impression that the library currently requires a two step process:
MakeExtension adds the Function type to deprecated: SavedImage->Function.
Then, AddExtensionBlock must be called to add it to SavedImage->ExtensionBlock
(The Function type is passed in via the SavedImage->Function so that's why we
have to do that step first.  Need to untangle those functions.)
- Why do we have so many colormaps?  GifFile->SColorMap is the screen
  descriptor colormap.
  GifFile->Image.ColorMap ?
  GifFile->SavedImages[x].ColorMap = Local colormap

- Also check how we push the Extensions out to a gif file.  We should never
touch SavedImage->Function when we write to file.  All information is saved in
the ExtensionBlock.

EGifPutExtension*/DGifGetExtension* needs to be looked at.  Why is there a
First, Next, Last, and generic version of these functions?  Does the
application programmer really need to know all this?  Shouldn't the library
take care of it?  Also, they should use WRITE rather than fwrite directly to
output the data.

Make sure we set pointers that we don't fill to NULL.  (gifalloc.c seems
pretty clean.  But GifFile isn't allocated in gifalloc.c)

I found a reported bug about libungif not handling interlaced images
correctly.  However, the latest library seems to work.  Need to figure out
what change fixed it and if it fixed it correctly or in a manner that is
apt to break later.

Make sure tmpnam is secure in gifinto.c (Use mkstemp if possible..)

Audit for sprintf => snprintf

# Make sure all malloc calls check their return value.
Still need to check dev2gif.c (Know there's problems there)
dgif_lib.c
egif_lib.c

Merge the windows changes from the last cvs version.  Contact Lennie Araki
about whether he is interested in maintaining the windows changes

Run the utils through indent

Make sure the backlog is really all merged and then delete things from there.
Some is in my mailbox at home.  Others were on the old CVS server.  I think
most of the CVS backlog has been merged but I've just started ot look at
the stuff at home.

Start thinking about function naming and standardizing things.  The MakeXXX,
FreeXXX is a good step, but should things operate on GifFiles or the interior
data structures?  What about the functions in the rest of the library?
Should I be able to (MakeGifFileType(), FreeGifFileType(GifFile *) just like
MakeMapObject?)

Start thinking about namespacing all our code!  This will break so many things
in simple ways.  Need to deprecate so we can do this in 5.0

Release 4.1.3

sync giflib

=======

Theoretical release 5.0

Move utilities into a separate package.
  - Move GIF_ERROR and GIF_MESSAGE from gif_lib.h into getarg.
  - Move qprintf into getarg 
  - Rename getarg utilsupport.a and move to the util directory.

Now that we have sourceforge hosting, look into putting documentation and a
website onto sourceforge.  Don't know how much stuff I want to sync into this,
though, as I keep hoping gif's will take their last gasp and die.  (Why do we
need gif now that we have png and mng?)

======

Besides fixing bugs, what's really needed is for someone to work out how to
calculate a colormap for writing gifs from rgb sources.  Right now, an rgb
source that has only two colors (b/w) is being converted into an 8 bit gif....
Which is horrendously wasteful without compression.

Any volunteers?

=======
The Present Extension code is pretty hacky.  It looks like giflib's ability to
do Extension code was added on at a later time and also was not implemented
entirely in conformance with the gif89a spec.  I've hacked it further to make
it conform to the spec, but it would benefit greatly from a complete rewrite.

If there is ever a version-5.0 of this library (with API level changes), this
should definitely be one of the areas that gets worked on.

=======
Documentation needs updating to reflect additions to the API.  This would best
be done with auto-extraction from the SOURCES....

=======
[UPDATE at bottom]
Here's a change to the library code that has been proposed:  Pulling known
extensions (comment blocks, etc) out of the Extensions array and putting them
in actual places within the GifType structure so application programmers don't
have to search through the Extension array for them.

I'm not sure how I want to implemement this yet -- Actually removing them from
the extension array would break the API compatibility with libungif.  Making
copies would waste resources needlessly.  Making convenience links with the
idea of deprecating the access of the extension block directly for standard
features would be okay, but creates extra work in the long run -- really we
need to put the convenience links into the current Extension array.

We have to decide where in the structure each extension belongs, generalize
the AddExtensionBlock function to be able to add the extensionblock to any
area of the structure, rework the gif writing code to place the structures
where they belong, rework the code writing to the Extension Array so that it
can handle links as well as blocks.

And on the other hand, it could turn out that putting extensions into the main
structure is not intuitive to everyone.  Extensions are "extensions" and
people may want to look for them grouped together.... I suppose this could
either mean leaving everything in the extension array, or creating a new
extension field that has the extensions dangling off of it (comment, gifanim
stuff, unknown, etc.)  This is okay except that it'd be best to have real
copies of the extension in the fields instead of links (so that we could make
arrays rather than arrays of pointers.)

[UPDATE:1998 3 Dec]
After reading through the gif89a specification, I'm not sure this is all that
great.  It seems that each image in a gif stream needs to have separate
extension blocks.  This means that an animated gif will have a Graphics
Extension Block for each Image in the animation.  Linking this up to the
GifFileType is wrong.  Making a link in each SaveFile is correct, but will
take space that won't be needed when that particular extension doesn't appear
in this file....

Unless someone wants to correct me here, I don't think I'm going to implement
this.