I’ve just shipped the 5.0.0 release of GIFLIB, a graphics service library that is deployed pretty much everywhere that throws pixels on a display. Older versions live in your browser, your game console, and your smartphone. I have written about what it was like to go back to this code after 18 years previously, in The Long Past of C; also in my 4.2.0 release announcement.
This version, as promised, fixes the portion of the API handling GIF extension blocks. I made one other change that is visible and not backward-compatible; the GIF file opener functions now take a final pointer-to-int where they’ll deposit an error code if they fail.
The reason for this change was to make the library fully thread-safe. The old API featured a shared static error cell analogous to Unix errno, but I actually got a bug report reminding me that is really not good design practice in the 21st century. Functions that operate on an existing (GifFileType *) set a new Error member when they fail, but the file-openers can’t do that – they return a null (GifFileType *) on failure, and changing that would have caused all kind of subtle problems for which client-application developers would rightly have cursed me.
Other new features include direct support for editing GIF89 graphics control blocks (yes, this is a feature we should have had in 1990), interlace handling in the DGifSlurp()/EGifSpew() high-level interface, and better handling of trailing extension blocks not attached to an image.
I also tossed out a lot more utility code. Basically, if a utility duplicated something that ImageMagick convert(1) or the Python Imaging Library can do, I threw it away. Those projects specialize in image composition and transforms and they do it very well; there’d be less than no point in trying to compete with them, especially since they’re using GIFLIB internally anyway.
Another important feature is that GIFLIB now has a really stringent regression-test suite (I spent a lot of the last couple of weeks on this). It’s also Coverity and cppcheck clean. So I’m expecting this code to be pretty stable. It would suit me fine if I didn’t have to think about it for another 18 years.