2012.07.26 19:43 "Re: [Tiff] Confused about 4.0 API changes: TIFFField vs TIFFFieldInfo", by Tom Lane

On Wed, 25 Jul 2012, Tom Lane wrote:

What the freeimage source code is doing with the TIFFFieldInfo stuff is determining the tag data type and the number of values, so that it can figure out how to call TIFFGetField to copy the data, without needing bespoke code for every possible tag. I suppose I could replace that with hard-wired code for each tag they care about, but that surely does not seem like an improvement.

Can anyone explain to me how to do this with the 4.0 API? If it's not possible, isn't that a rather serious functionality regression?

I did not make this change and don't see how to achieve the function with the current interface. It is likely that these structures were hidden because they are internal implementation structures which should not be frozen in an ABI. New accessor functions can be added to query whatever useful information is available/necessary via this handle.

It appears to me that to be able to know how to call TIFFGetField and TIFFSetField, applications need access to all of these fields:

        short field_readcount;                  /* read count/TIFF_VARIABLE/TIFF_SPP */
        short field_writecount;                 /* write count/TIFF_VARIABLE */
        TIFFDataType field_type;                /* type of associated data */
        unsigned char field_passcount;          /* if true, pass dir count on set */

In addition it'd probably be handy to provide access to

        char* field_name;                       /* ASCII name */

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?)

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.

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.

regards, tom lane