Thread

No, I think the real bug is that TIFFFdOpen() should take a thandle_t as its first parameter instead of int. Given the File I/O agnostic interface of libtiff, there's no point in have a function that specifically only opens a tiff file from specifically an fd anyhow. This does raise interface compatibility issues but I assume bigtiff breaks ABI compability anyhow?

-Edward

OK... what would be a good way of fixing it? Doesn't look like TIFFFdOpen interface should be changed; I'm not sure why is it used to pass Windows HANDLEs, sounds confusing (as Windows has normal int file descriptors as well). Should we add new functions TIFFHndlOpen or something like that? Win32 only?

On Mon, Aug 11, 2008 at 3:29 PM, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote:

> On Mon, 11 Aug 2008, Mikhail Kruk wrote:
>
>> I'm trying to build LibTiff for 64 bit Windows.
>> I'm not sure what's the best way to handle this problem in tif_win32.c
>> (in TIFFOpen()):
>>
>> tif = TIFFFdOpen((int)fd, name, mode);
>>
>> fd is a void * which is 64 bit on Windows, int is 32 bit.
>

This does seem like a problem, particularly if the extra bits are actually > used. I don't believe that libtiff has been ported to 64-bit Windows even

> though it mostly works ok for 64-bit Unix systems. 64-bit Windows is strange > since 'long' is still 32-bits.

>
> Since this seems like a new area for libtiff, I recommend using the

> 4.0.0beta2 preliminary release, or libtiff CVS, so that it is easier to > formulate and test fixes. Old releases are never fixed.

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