2005.01.28 19:58 "Re: [Tiff] issues with TIFFStreamOpen", by Frank Warmerdam

The TIFFStreamOpen() code was previously using tiff 3.4 which didn't have this extra call to TIFFSeekOpen() from TIFFClientOpen().

The comment in TIFFClientOpen() is still suspicious though:

/*
  * This seek shouldn't be necessary, but I have had some
  * crazy problems with a failed fseek() on Solaris leaving
  * the current file pointer out of whack when an fwrite()
  * is done.
  */
TIFFSeekFile( tif, 0, SEEK_SET );

if (!WriteOK(tif, &tif->tif_header, sizeof (TIFFHeader))) {
        TIFFError(name, "Error writing TIFF header");
        goto bad;
}

Does anyone know why this was added? (Frank? Andrey?) The comment doesn't even make sense. Prior to the call to TIFFSeekFile() in TIFFClientOpen(), there's no calls to fwrite at all. We only call WriteOK() *after* calling TIFFSeekFile(). So this means that if WriteOK() was messing up the file pointer, then doing the seek before wouldn't have an effect anyhow. Another problem with this code is that WriteOK() will not call fwrite() in general anyhow as WriteOK() ultimately just resolves to tif_writeproc which is passed down to TIFFClientOpen(). There's no requirement that tif_writeproc uses fwrite().

Edward,

I added the seek and the rather incoherent comment. As I recall it really did work around some funky problem on Solaris. However, I didn't reference a bug report nor provide a coherent explanation about it so I would not mind if it was removed again.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent