AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.10.21 15:50 "Problems catching write errors in tiff library (v3.3beta021)", by Ben Griffin
1994.10.21 03:20 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Richard Minner
1994.10.21 05:53 "Re: C++ tiff library", by Richard Minner
1994.10.21 23:15 "Re: C++ tiff library", by Yip Chi Lap
1994.10.21 14:38 "Re: C++ tiff library", by Richard Minner
1994.10.25 20:49 "Re: C++ tiff library", by John M Davison
1994.10.31 04:52 "Re: C++ tiff library", by Richard Minner
1994.10.21 17:12 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Dan McCoy
1994.10.21 18:36 "C++ tiff library", by Jim Arnold
1994.10.21 18:53 "Re: Problems catching write errors in tiff library (v3.3beta021)", by John Bradley
1994.10.21 19:16 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Sam Leffler
1994.10.21 19:13 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Sam Leffler

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.

Thanks.

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.

    Sam