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
August 2017

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

2017.08.02 15:00 "Error handling in Read/Write/Seek", by Nicolas Ruff
2017.08.02 15:26 "Re: Error handling in Read/Write/Seek", by Bob Friesenhahn
2017.08.03 15:04 "Re: Error handling in Read/Write/Seek", by Nicolas Ruff
2017.08.03 15:23 "Re: Error handling in Read/Write/Seek", by Bob Friesenhahn
2017.08.04 15:27 "Re: Error handling in Read/Write/Seek", by Even Rouault
2017.08.07 15:53 "Re: Error handling in Read/Write/Seek", by Nicolas Ruff

2017.08.03 15:04 "Re: Error handling in Read/Write/Seek", by Nicolas Ruff

> It seems best to block any negative size values from being passed into these
> functions in the first place.  Libtiff is not in control of the I/O
> functions, so it is best to assure that they are not passed illegal values
> which might cause I/O implementations to do very bad things.

Not sure to understand what you mean here. Here are all call locations
for SeekOK():
tif_dir.c : 2 times
tif_read.c : 4 times
tif_write.c : 1 time
tif_dirread.c : 3 times
tif_dirwrite.c : 9 times

Do you suggest to add an extra check for (off<0) before each call? If
yes, I can prepare a patch.

Also, is there any chance that TIFFSeekFile() could legitimately be
called with off<0 and whence=SEEK_CUR? I mean, is there any reason to
seek backward in a TIFF file? Looking at the code, the only calls to
TIFFSeekFile(whence=SEEK_CUR) take (dircount*object_size) as an offset
and should therefore always be positive, but I am not super-familiar
with TIFF format(s).

Thank you,
- Nicolas RUFF