giflib 4.2.0 released

First giflib release since I reassumed the lead. Short version: lots of useless old cruft thrown out, everything Coverity-scanned, one minor resource leak found and fixed.

As I’ve previously noted, this code was in astonishingly good shape considering its great age. I vigorously beat the dust out of it with Coverity and cppcheck, but found only one very minor bug that way – a malloc leak following a malloc failure in the code that makes color-table structures. I think it is rather likely this case has never actually been triggered.

I retired six utilities, added a bunch of documentation and made it HTML-able, fixed a minor bug in how output GIF versions are computed in an upward-compatible way, and fixed a thread-safety problem. I added a rudimentary regression-test suite; this could use some more work. All tracker bugs have been resolved and closed.

Next release, 5.0, will make one very minor change in the API near extension blocks.

16 comments

  1. “Next release, 5.0, will make one very minor change in the API near extension blocks.”

    Is that API change breaking backward compatibility?

    1. >Is that API change breaking backward compatibility?

      Only with regard to two undocumented functions. And a member is being removed from one of the internal structures, so the object library won’t be compatible and the major version has been bumped. But the public API is unchanged.

  2. Was support for the Utah Raster Toolkit removed? Not that it matters much — I’m sure there is no code of consequence that relies on that anymore, but I have some historical interest.

    1. >Was support for the Utah Raster Toolkit removed?

      Yes. The RLE support consisted of two conversion utilities. That job is handled just as well by ImageMagick, and dropping the utilities eliminated an external dependency on the RLE library,

  3. “so the object library won’t be compatible and the major version has been bumped”

    This is what I was getting at. It’s refreshing to see proper version numbering, which only bumps the integer portion of the number when backward compatibility is broken. I’m getting tired of numbering being based on irrelevant concerns such as marketing.

  4. I’m getting tired of numbering being based on irrelevant concerns such as marketing.

    I sense a disturbance in the force…as if a thousand Finnish software engineers cried out and were at once silenced…

  5. I noticed two broken links on : and under “The GIF standard” return 404s. Also the hyperlink in “You can find his home page at http://www.ccil.org/esr.” is correct but the text of the link itself returns a 404. If I may, I’d suggest adding a link to Gifsicle somewhere. I find it to be a great tool.

    Thanks for your work on free software.

  6. lots of useless old cruft thrown out

    What % of the source code went away?

    What % reduction of the compiled binary?

    1. >What % of the source code went away?

      10.8KLOC shrunk to 8.6KLOC, so about a 20% reduction in source code. 6 of 32 utilities were discarded.

      >What % reduction of the compiled binary?

      Not an interesting measure; the library size barely changed at all, and the build doesn’t generate one binary but a large collection (formerly 32, now 26) of small binaries.

  7. @Rich Rostrom:

    Actually, one of the interesting things about a nearly 2-decades old library that has seen massively widespread use on every platform from Unix to Mac to Android to Windows to BeOS, and has been linked against thousands of applications is that the codebase is extremely well vetted. Most of the bugs that have ever been in it were fixed long before esr retook ownership. And it’s probably been thoroughly optimized and tightened as well as possible without affecting code readability or maintainability or functionality. So giflib is probably about as stable and mature as any codebase you’ve ever seen.

    So I wouldn’t be too surprised if the difference in the size of the actual resulting binary is quite small.

    But heck, it’s open source. So you could just grab it and the preceding version and compile it on your OS of choice and find out for yourself. :)

    1. >Most of the bugs that have ever been in it were fixed long before esr retook ownership.

      And there weren’t many bugs to begin with. Gershon Elber did a good job on the original code, and I managed to refrain from screwing things up when I wrote the higher-level API for it. The code barely changed during the years I was gone. In fact, looking at the git history and the CVEs, it looks as though the only bugs anyone has ever managed to find since 2005 were memory leaks in a couple of rare error cases.

      >And it’s probably been thoroughly optimized and tightened as well as possible without affecting code readability or maintainability or functionality.

      There was never much to optimize in the GIF stuff, really. Well defined task, fairly obvious mapping to one right way to do it, little scope for tricks. The LZW code might have been an optimization target, but I and Toshio both left that the hell alone. I’m betting his reason was the same as mine – no reasonably expectable amount of optimization gain would have been the worth of introducing bugs,

      >So giflib is probably about as stable and mature as any codebase you’ve ever seen.

      That it is. And I don’t intend to mess with success. There was one mis-design in the extension handling that had needed to be fixed for years, hence 5.x – but I’m fully expecting 5.x to go for half-decades at a time between releases.

  8. If giflib is now written against C99 instead of C89, you may have a problem on Windows. Visual Studio is a C++ development environment, and Microsoft has indicated that their compiler will not track the C standard beyond C89, putting all of its effort into C++; consequently, a lot of C99 code breaks (though if you limit yourself to certain features (like C99 integer types), you can get away with it by including certain header files). If your code doesn’t compile on Visual Studio, you’re basically out of the Windows market.

    Toxic hellswamp though it may be, it’s still the desktop OS that most PC users will be using for quite some time.

Leave a Reply to Morgan Greywolf Cancel reply

Your email address will not be published. Required fields are marked *