GIFLIB 5.0.0 is released
<p>I&#8217;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 <a href="http://esr.ibiblio.org/?p=4304">The Long Past of C</a>; also in my <a href="http://esr.ibiblio.org/?p=4351#more-4351">4.2.0 release announcement</a>.</p>
<p><span id="more-4397"></span></p>
<p>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&#8217;ll deposit an error code if they fail.</p>
<p>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&#8217;t do that &#8211; they return a null (GifFileType *) on failure, and changing <em>that</em> would have caused all kind of subtle problems for which client-application developers would rightly have cursed me.</p>
<p>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.</p>
<p>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&#8217;d be less than no point in trying to compete with them, especially since they&#8217;re using GIFLIB internally anyway.</p>
<p>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&#8217;s also Coverity and cppcheck clean.  So I&#8217;m expecting this code to be pretty stable. It would suit me fine if I didn&#8217;t have to think about it for another 18 years.</p>
