2004.07.11 17:27 "Re: [Tiff] unintentional ABI change between 3.5 and 3.6?", by Andrey Kiselev

Executive summary: after additional experimentation, I no longer believe that there was an ABI change between 3.5.7 and 3.6.1. Read on for details....

It seems to me that the TIFFDirectory, _TIFFRGBAImage and TIFF structure contents are not intended to be used publically. I am not familiar with what resulted in the TIFFYCbCrToRGB structure change or what it is used for, so I am not clear on whether this is really a change to the public ABI or not.

I've done a bunch of experimentation this morning and agree with your conclusion. I have compiled various programs that follow the TIFF interface correctly and have not been able to create a situation where a program compiled with libtiff 3.5.7 and run with 3.6.1 or vice versa behaves incorrectly. It is also clear that libtiff uses the well established technique of hiding the structures from the public interface through an opaque typedef. This even isolates the client applications from changes in the sizes of the data structures.

There was one change: the structure

typedef struct {                                /* YCbCr->RGB support */
        TIFFRGBValue* clamptab;                 /* range clamping table */
        int*    Cr_r_tab;
        int*    Cb_b_tab;
        int32*  Cr_g_tab;
        int32*  Cb_g_tab;
        float   coeffs[3];                      /* cached for repeated use */
} TIFFYCbCrToRGB;

becomes

typedef struct {                                /* YCbCr->RGB support */
        TIFFRGBValue* clamptab;                 /* range clamping table */
        int*    Cr_r_tab;
        int*    Cb_b_tab;
        int32*  Cr_g_tab;
        int32*  Cb_g_tab;
        int32*  Y_tab;
} TIFFYCbCrToRGB;

I have made that change because that structure previously was used internally in libtiff, so it should be safe to change it.

If I can demonstrate conclusively that this is not the result of an ABI change, then I'll retract my request to call the next release 4.0.0 and change its soname on that basis. Of course, it may still be a good idea to decouple the soname and library version as discussed in your message and other responses, but it could be done just because it's a good idea to do in conjunction with moving to libtool rather than because of this specific problem.

It will be more valuable reason to change the soname soon. We are working on TIFF format extension able to deals with the large files (>4GiB), that will certainly results in large ABI change (uint32 will become uint64 in many places).

Andrey

Andrey V. Kiselev
Home phone: +7 812 5274898 ICQ# 26871517