AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2005

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2005.01.25 18:29 "issues with TIFFStreamOpen", by Michael Rinne
2005.01.27 19:45 "Re: issues with TIFFStreamOpen", by Edward Lam
2005.01.27 21:51 "Re: issues with TIFFStreamOpen", by Edward Lam
2005.01.28 10:28 "Re: issues with TIFFStreamOpen", by Michael Rinne
2005.01.28 16:24 "Re: issues with TIFFStreamOpen", by Edward Lam
2005.01.28 16:45 "Re: issues with TIFFStreamOpen", by Michael Rinne
2005.01.30 12:02 "Re: issues with TIFFStreamOpen", by Andrey Kiselev
2005.01.30 23:19 "Re: issues with TIFFStreamOpen", by Edward Lam
2005.01.31 21:20 "Re: issues with TIFFStreamOpen", by Michael Rinne
2005.01.28 19:58 "Re: issues with TIFFStreamOpen", by Frank Warmerdam

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

On Thu, 27 Jan 2005 14:45:14 -0500, Edward Lam <edward@sidefx.com> wrote:
> 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