2007.07.14 08:00 "[Tiff] [ANNOUNCE]: Libtiff 3.9.0beta released", by Andrey Kiselev

2007.07.26 14:54 "Re: [Tiff] possible ABI change in 3.9.0 beta?", by Bob Friesenhahn

I normally think of the TIFFRGBAImage structure as internal to the library but I suppose it is legal for applications to provide custom functions for use with it that are dependent on the internals of this structure so it is indeed public.

The comments in tiffio.h suggest that applications can/should use this structure, and since it is in a non-private structure it must be part of the public interface. The interface is formally documented in libtiff documentation, with a direct link to the documentation ("TIFFRGBAImage Support") from the main API description page at http://remotesensing.org/libtiff/libtiff.html. This page recommends allocating TIFFRGBAImage on the application's stack.

The reason that libtiff in debian uses soname 4 rather than 3 is because of a change in that very structure at some point in the distant past (like 3.6.1 or something) which broke a whole bunch of gnome-based image processing programs, so it is most definitely part of the public interface.

This structure is a terrible thing to expose as it is. If it still needs to be publically exposed, this would be a good time (in 4.0) to add copious padding to the end of the structure definition so that new members can be added after existing members using the reserved space. This approach assumes that libtiff is responsible for initializing the structure. Another forward-looking approach is to provide an allocation fuction so that libtiff allocates TIFFRGBAImage from the heap rather than on the using application's stack. This approach only requires that libtiff keep existing members in the same position.

Does anyone have an idea how many applications are using TIFFRGBAImage?

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/