AWare Systems, Home TIFF and LibTiff Mail List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
November 2018

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
Archive maintained by AWare Systems

New Datamatrix section

Valid HTML 4.01!


2018.11.10 19:39 "[Tiff] Libtiff 4.0.10 is now available", by Bob Friesenhahn
2018.12.11 14:24 "Re: [Tiff] SeekOK and WriteOK", by Emmanuel Cosnard
2018.12.11 14:01 "Re: [Tiff] SeekOK and WriteOK", by Bob Friesenhahn
2018.12.11 14:09 "Re: [Tiff] SeekOK and WriteOK", by Emmanuel Cosnard
2018.12.11 14:29 "Re: [Tiff] SeekOK and WriteOK", by Nicolas RUFF

2018.12.11 14:01 "Re: [Tiff] SeekOK and WriteOK", by Bob Friesenhahn

> Hello,
> I am using the function TIFFWriteData to write some data on a custome rationnal tag, and it seems, that on some rare occasion,
> if (SeekOK(tif, dir->tdir_offset) && WriteOK(tif, cp, cc))
> Is there a way to do some intelligent retry here, instead of returning an error? Or can we know why the WriteOK or SeekOK didn't work properly?

You did not mention the operating system you are using or the size of
its native off_t type (or equivalent). It might make a difference if
you are using tif_unix.c or tif_win32.c, and the capabilities of the
compiler and run-time when the library was compiled.

This is the underlying implementation of the check:

int _TIFFSeekOK(TIFF* tif, toff_t off)
     /* Huge offsets, especially -1 / UINT64_MAX, can cause issues */
     /* See */
     return off <= (~(uint64)0)/2 && TIFFSeekFile(tif,off,SEEK_SET)==off;

One can see that the first check is that the offset must be within the
range of a signed 64-bit type. The next check actually does the seek
and checks if the requested position was obtained. This is a case
where the seek position might need to be in the range of a smaller

 Bob Friesenhahn,
 GraphicsMagick Maintainer,

Public Key,