2010.06.17 15:39 "[Tiff] libtiff 4 API/ABI stability?", by Adam Goode

2010.06.17 22:06 "Re: [Tiff] libtiff 4 API/ABI stability?", by Edward Lam

On 06/17/2010 12:21 PM, Edward Lam wrote:

I was wondering if there are going to be any API or ABI incompatible changes before the final release of libtiff 4.

If you care about Windows, bug 1941 [1] is still open. If it gets fixed, then the behaviour for the following functions will change on Windows: TIFFFdOpen(), TIFFFileno(), TIFFSetFileno(), TIFFClientdata(), TIFFSetClientdata().

I am not quite as concerned with Windows behavior as Unix, since shipping dependent DLLs is the norm on Windows, but this could change if CoApp[1] becomes popular (as I hope it does).

I think this should be fixed before libtiff 4. Is anyone interested in making a release blocker bug in bugzilla? We could add this bug to it.

I could if we get some maintainer is willing to look at it for libtiff 4.

Also, I wonder why the tif_win32.c file isn't enabled by default on Windows. With tif_unix.c, the file interface is limited to 2GB on Windows. tif_win32.c is needed for large file access (the whole point of libtiff 4?).

Sorry, I think that I'm wrong on this. It does look like tif_win32.c is the default. On the note of tif_unix.c for Windows, I think we only need to patch it _lseeki64 to work for large files?