9 lines
2.4 KiB
Plaintext
9 lines
2.4 KiB
Plaintext
GIFLIB 5.0.0 is released
|
|
<p>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 <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’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’t do that – 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’d be less than no point in trying to compete with them, especially since they’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’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.</p>
|