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:23 "Re: Error handling in Read/Write/Seek", by Bob Friesenhahn

On Thu, 3 Aug 2017, Nicolas RUFF wrote:

>> 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.

Yes, I am suggesting that it is best to avoid passing a wrong request 
to the I/O functions (which might have been implemented by a library 
user or are implemented in a C library on any operating system libtiff 
may be compiled on) rather than dealing with a subsquent possible 
error return due to the wrong request.  This approach assures 
consistent behavior.  It can also produce a better quality (more 
appropriate) error message for the library user.

> 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).

I don't know what might happen in the future.  We only know what 
libtiff does now.  The seek operation used should be apparent at each 
call point.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/