-
2017.08.02 15:26 "Re: [Tiff] Error handling in Read/Write/Seek", by Bob Friesenhahn
-
2017.08.03 15:04 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
- 2017.08.03 15:23 "Re: [Tiff] Error handling in Read/Write/Seek", by Bob Friesenhahn
- 2017.08.04 15:27 "Re: [Tiff] Error handling in Read/Write/Seek", by Even Rouault
-
2017.08.03 15:04 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
2017.09.06 10:32 "Re: [Tiff] Error handling in Read/Write/Seek", by Even Rouault
On mercredi 6 septembre 2017 09:48:18 CEST Nicolas RUFF wrote:
Sorry to resurrect this old thread, but I came up with a much simpler patch:
--- libtiff/tiffiop.h 2017-07-04 15:28:42.000000000 +0200
+++ libtiff/tiffiop.h 2017-09-05 13:38:02.305947462 +0200@@ -239,7 +239,7 @@
#endif
#ifndef SeekOK
#define SeekOK(tif, off) \
- (TIFFSeekFile((tif),(off),SEEK_SET)==(off))
+ (((off_t)(off) >= 0) && TIFFSeekFile((tif),(off),SEEK_SET)==(off))
#endif
#ifndef WriteOK
#define WriteOK(tif, buf, size) \The rationale behind is described in http://bugzilla.maptools.org/show_bug.cgi?id=2726#c4
Would you consider this patch for inclusion?
One potential issue I can see is that we use off_t here, which isn't necessarily what is use in the implementation of the file system callbacks. For example tif_unix.c uses _TIFF_off_t. I'm wondering for example if off_t might not be 32 bit only in some circumstances when evaluated in libtiff non-IO code.
--
Spatialys - Geospatial professional services
http://www.spatialys.com