- 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 17:12 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Dan McCoy
- 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:
- TIFFClose should return an error value. Now it only a void, but a TIFFFlushData can happen during the call so it should return the results of that.
- I'm not sure if it is ok to assume that -1 is failure from TIFFCloseFile() since that might not always be the unix close command.
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.
- In tif_fax3.h the Fax3FlushBits macro calls TIFFFlushData1 without checking return value. Then each function that uses Fax3FlushBits should return a value.
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