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.
“It would suit me fine if I didn’t have to think about it for another 18 years.”
That, I believe, falls into the category of “famous last words”. Or, as Howard Tayler puts it, “don’t taunt Murphy”.
Jay said:
I kinda like the way WCC put it (in a comment earlier this spring):
“Murphy is omnipresent, the bastard.”
>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.
Be funnier than a very funny thing if they used the utility code in GIFLIB internally. And yes, I’m sure you checked.
>Be funnier than a very funny thing if they used the utility code in GIFLIB internally. And yes, I’m sure you checked.
It would be, but no. What these tools actually do is lift particular image formats like GIF into an internal form that’s basically a raster array of RGB pixels with attached metadata, then they do transforms on the raster, then they render the result to whatever output file format you want. The core library of GIFLIB gets used on both ends if this pipeline if you happen to be messing with a GIF.
As great as it’d be to have such stable software that you won’t need to touch it for 18 years, it’s already a bit surprising that GIFLIB still has a use in 2012…
Why, Mike? The GIF format is ubiquitous in no small part because it’s pretty good. Sure, there’s better stuff out there, but not as ubiquitous: anything that deal with images handles GIF, even if it handles nothing else. There’s simply no compelling reason to transcode all the masses of GIFs out there to some other format.
>There’s simply no compelling reason to transcode all the masses of GIFs out there to some other format.
Not since the blocking patents expired, no. The design of GIF is a little old and crufty, but basically sound. PNG has better compression, but that’s only a small incremental improvement. GIF is adequate for images with 256 or fewer colors and 8-bit color depth.
I’m not much of a programmer, just a little scripting, but your stripping functions out of the code bothered me a bit. Now Jamie Zawinski has this about the OpenGL specification:
>Let’s say you have a well-specified system that is in wide use (a language, a library API, whatever) and because of changes in some substrate (operating systems, hardware, whatever) you find that you need to add a new way of doing things to it.
>The way you do this is, you add new features to the specification and you clearly document the version in which those features become supported.
>If there are old features that you would like to discourage the use of, then you mark them as obsolete — but you do not remove them because thou shalt not break working code.
>If you don’t agree with that, then please, get out of the software industry right now. Find another line of work. Please.
I think part of the reason for that view is because people still associate GIFs with happy-coloured crappy, crude little animations from the old-style web. Anyway I like PNGs for sharp graphics and JPGs for photographic-style images.
billswift: He was talking about removing unnecessary utility programs that came with the distribution. Not API calls. The only API alteration he mentioned was the error code change in the file-opener functions – I assume this will affect the function signature and require intervention for a successful compile against the library.
Not having looked at the old/new code, I am not sure what provision Eric made for backwards compatibility, like defaulting to the old behavior if a NULL pointer is passed. Since it’s C, there is no function overloading.
>He was talking about removing unnecessary utility programs that came with the distribution. Not API calls
Correct.
>I assume this will affect the function signature and require intervention for a successful compile against the library.
Also correct. This change will break compilation of the code in a noisy, obvious way, then be easy to fix. When you have to change an API incompatibly, that’s how to do it.
>like defaulting to the old behavior if a NULL pointer is passed.
If a NULL pointer is passed, you don’t get an error code back on failure. The old-style errno-equivalent is truly gone.
Thanks, like I wrote I am not a programmer, but I have read a good bit about computers since I started using them, and that had been bothering me a little.