LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.07.11 17:27 "Re: unintentional ABI change between 3.5 and 3.6?", by Andrey Kiselev
On Sun, Jul 11, 2004 at 12:47:12PM -0400, Jay Berkenbilt wrote:
> 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