2012.07.26 02:50 "[Tiff] Confused about 4.0 API changes: TIFFField vs TIFFFieldInfo", by Tom Lane

2012.07.26 20:18 "Re: [Tiff] Confused about 4.0 API changes: TIFFField vs TIFFFieldInfo", by Bob Friesenhahn

So I propose we add five trivial accessor functions:

        int TIFFFieldReadCount(const TIFFField*);
        int TIFFFieldWriteCount(const TIFFField*);
        TIFFDataType TIFFFieldDataType(const TIFFField*);
        int TIFFFieldPassCount(const TIFFField*);
        const char* TIFFFieldName(const TIFFField*);

that just fetch the indicated field (and, probably, dump core if passed a NULL pointer - is there use in something more complex?)

These look good to me.

How much effort do we want to put into doing this? I could imagine deciding this is an ABI break, inventing a new symbol classification in libtiff.map, etc. I'm not personally excited about doing that, in part because Red Hat hasn't shipped 4.0 yet and so has no stake in ABI compatibility issues. Other people might be more demanding.

This does not seem like an ABI break since nothing has been changed or taken away. It is only an issue if an application is copied from a system with a newer libtiff to a somewhat older one. In that case it should simply report not being able to find the required shared library (and fail to run). The user would then need to update their libtiff to the newer one. At least I think that is what should happen.

The libtiff symbol versioning is primarily intended to resolve problems if two incompatible libtiffs are loaded at once. The libtiff with the higher major number is still compatible because its age is increased such that the baseline interface version is still the same.

In any case I'd like to get this done ASAP, because Fedora freeze deadlines are nearing. I'm willing to do the legwork and commit the code changes if there are not objections, but someone else would have to manage pushing a new release out.

I am still willing and able to produce libtiff releases as required.

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