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

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) \
 ((*(tif)->tif_readproc)((tif)->tif_clientdata,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.

if (tif)
  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?

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html