2004.08.25 17:35 "[Tiff] Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Joris Van Damme

2004.08.26 09:27 "Re: [Tiff] Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Joris Van Damme

Please note that for some reason the tif_fd member is used by the tiff2pdf program. I'd be happy to just use tif_clientdata instead, a fix of a few lines.

It is used in the fax2tiff program for the "smuggling of the file descriptor" and in the tiff2pdf program for enabling TIFFWriteFile functions to stdout.

If the tif_fd is never otherwise addressed in the library code then it should be a simple matter to remove it.

OK, then that seems a worthy course of action, whether we remove the tif_fd or not, because it will serve in 'cleaning up' either way.

It can be presumed that other software uses the field.

 * Return open file's I/O descriptor.
TIFFFileno(TIFF* tif)
        return (tif->tif_fd);

What are the benefits of so doing besides the encapsulation of the type? If the benefits of encapsulating the type, if that is the right notion, outweigh breaking some existing programs which are easily updated if part of libtiff, then it would be worth doing. Let us not be too hasty. casual source code browsing does appear that it's OK to take it out.

Let's indeed not be hasty. But let's try to nevertheless be clean, maybe we can have it both ways.

How about this:

How does this sound to you?

Joris Van Damme
Download your free TIFF tag viewer for windows here: