1994.10.21 15:50 "Problems catching write errors in tiff library (v3.3beta021)", by Ben Griffin

1994.10.21 19:13 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Sam Leffler

Version: 3.3beta021 Host: Sparc Solaris 2.3

There seems to have an incongruity in the return types of the tiff_encoderow functions as follows.

   TIFFNoRowEncode returns -1 on failure.
   DumpModeEncode  returns -1 on failure.
   Fax3Encode      returns  0 on failure.
   Fax4Encode      returns  0 on failure.
   LZWEncode       returns  0 on failure.
   PackBitsEncode  returns -1 on failure.

This can cause TIFFWriteScanLine to return a non -1 value (0) which does not indicate an error. I discovered this after running disk full tests with our app which uses the tiff library.

I guess you are safe if you check for a success return value (1) from TIFFWriteScanLine, but I happend to be checking for the failure which is -1 according to the man page (I guess that is why it's beta eh?).

The fix (kludge) I put in tif_write to aleviate this is: line 155: (second to last line in TIFFWriteScanLine)

  if ( status == 0 ) status = -1;

I wouldn't do this. There's some trickiness that's evolved over time regarding error returns from the various encoders. The issue is that a single return value is insufficient to indicate whether a decoding failure is recoverable or not. For example, when a request to decode a scanline of G3-encoded data fails, but the decoder is able to resync at the EOL code then the caller is likely to want to continue. I think the right answer is here is to change the caller to look for !success rather than failure (i.e. -1). This is definitely an area of the manual pages that's lacking.

Other areas that could cause uncaught errors:

This is a big hole. If TIFFClose returns -1, then what does it mean? Is the file closed? What state are things in? If you really want to be 100% certain of the state of the image data then you need to do a flush by hand (it's ok since TIFFClose won't redo the work). I think that simply returning an error is insufficient unless the caller can identify what went wrong.


On another subject, there was some talk earlier about rewriting the tiff library in C++. Any progress on this? Want any help?

This is unlikely to happen anytime soon.