Sex, software, politics, and firearms. Life's simple pleasures…

Main menu

Post navigation

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.

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.

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

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.

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

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

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.