2004.08.26 04:46 "Re: [Tiff] Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Ross A. Finlayson

Thus, tif_fd seems redundant. And what's more, without this tif_fd setting in TIFFFdOpen, the complete platform dependent files like tif_win32 would be treating the TIFF* as opaque, which is a helpfull feature for some.

Upon a quick review, I am tempted to agree. It would appear we could drop the tif_fd member from the TIFF structure if no-one speaks up and points out a real need for it. I suspect it dates from a time before the clientdata existed.

Hello,

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.

[space:libtiffcvs-b/libtiff/tools] space% grep tif_fd *.c
fax2tiff.c:             faxTIFF->tif_fd = fileno(in);
fax2tiff.c:             faxTIFF->tif_clientdata = (thandle_t) faxTIFF->tif_fd;
tiff2pdf.c:             close(output->tif_fd);
tiff2pdf.c:             output->tif_fd=(int)fileno(stdout);
tiff2pdf.c:             CloseHandle((HANDLE) output->tif_fd);
tiff2pdf.c: output->tif_fd=(int)GetStdHandle(STD_OUTPUT_HANDLE);
tiff2pdf.c:             output->tif_clientdata=(thandle_t)output->tif_fd;

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.

In fax2tiff.c the lines are as so:

                ...
                in = fopen(argv[optind], "r" BINMODE);
                if (in == NULL) {
                        fprintf(stderr,
                            "%s: %s: Can not open\n", argv[0], argv[optind]);
                        continue;
                }
                faxTIFF->tif_fd = fileno(in);
                faxTIFF->tif_clientdata = (thandle_t) faxTIFF->tif_fd;
                ...

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

[space:libtiffcvs-b/libtiff/libtiff] space% grep -I tif_fd *.*
tif_acorn.c:            tif->tif_fd = fd;
tif_apple.c:            tif->tif_fd = fd;
tif_atari.c:            tif->tif_fd = fd;
tif_msdos.c:            tif->tif_fd = fd;
tif_open.c:     return (tif->tif_fd);
tif_unix.c:             tif->tif_fd = fd;
tif_vms.c:              tif->tif_fd = fd;
tif_win3.c:             tif->tif_fd = fd;
tif_win32.c:            tif->tif_fd = ifd;
tiffiop.h:      int             tif_fd;         /* open file descriptor */

Those are easy to remove if they have no side effects.

It can be presumed that other software uses the field.

/*
 * Return open file's I/O descriptor.
 */
int
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.

I've made some progress on yet another tag viewer. I have a question about how a DOUBLE type is stored in the file. Of the eight bytes, is it stored as two 32-bit words in the file's byte order? I'm hoping I can get a sample of an IPTC/NAA record, that is both Kodak and NAA/NSK or a RichTIFF file, and also I'd like a sample TIFF/EP and Exif TIFF file, if you happen to have one of those to test the software please let me know. Basically I'm at the point where I'm trying to determine how to get a separate little help window with different help for the field name and enumerated value. Actually I've figured that out and am procrastinating.

Good luck, have fun, have a nice day,...

Ross F.