2004.08.25 19:08 "RE: [Tiff] Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Neufeld Computer Services
I'm using it in some code, but it also looks redundant to me, and tif_clientdata would do as well.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Joris
In TIFFFdOpen, in tif_win32, there is a call to TIFFClientOpen. It feeds the file handle as clientdata the parameter. TIFFClientOpen sets the clientdata member of the newborn TIFF structure.
tif->tif_clientdata = clientdata;
That is needed, since there is next some calls to reading functions and the like, that may need this clientdata (as is the case in the tif_win32 of the file reading functions). The clientdata member is fed to the platform-dependent functions as 'fd' parameter.
#define ReadOK(tif, buf, size) \
(TIFFReadFile(tif, (tdata_t) buf, (tsize_t)(size)) == (tsize_t)(size))
#define TIFFReadFile(tif, buf, size) \
Upon return to TIFFdOpen, in tif_win32, this one, in turn, sets the fd member of the TIFF structure, with the same file handle value.
tif->tif_fd = ifd;
All equivalents of tif_win32 for all other platforms seem to do the same. However, throughout the library, this tif_fd member seems not ever used, as far as I can see. It would be too late for read procedures to use it anyway, they've already been called before this tif_fd value gets set.
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.
Is there something I'm missing?
Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html