2000.07.24 15:48 "TIFF Error handler", by Frank Warmerdam

Hi,

With regard to bug http://bugzilla.remotesensing.org/show_bug.cgi?id=4

I reviewed your bug report, and tried out some stuff with the test file you provided. I have concluded that the fax3 code is not causing the read to fail, even when it calls TIFFError() to report what is presumably supposed to be a fatal error.

eg.

warmerda@rommel.atlsci.com[124]% ./tiffcp ~/test.tif ~/out.tif |& more
Fax4Decode: /home/warmerda/test.tif: Bad code word at scanline 2273 (x 1907).
Fax4Decode: Warning, /home/warmerda/test.tif: Premature EOL at scanline 2273 (go t 1907, expected 2960).
Fax4Decode: Warning, /home/warmerda/test.tif: Line length mismatch at scanline 2 280 (got 2961, expected 2960).

...

So, the problem occurs not just when you install an error handler of NULL, but also when the default error handler is installed.

I had expected the libtiff code to return from the TIFFReadEncodedStrip() (or whatever) with an error indicator set, but that isn't what happens.

However, at this point I am somewhat hesitant to change the behaviour without a better understanding of why it is the way it is now. In particular, I am afraid that lots of developers are now depending on the fax3/fax4 decompression code to be quite forgiving of errors, and to try and go on and recover. If that is so, my making these errors suddenly fatal may be quite annoying.

I am cc:ing this message to the libtiff mailing list to see if anyone else has an opinion on what we should do. As I see it the options are:

1. Leave things as they are.
2. Make our policy of being forgiving about decompression errors for fax3/fax4 errors explicit by changing the calls to TIFFWarning().
3. Assume that calls to TIFFError() were meant to be fatal, and add appropriate error handling in the tif_fax3.c module to ensure that a fatal error (ie. via the unexpected macro) results in termination of the current strip or tile reading, and returning from the function with an appropriate error code.

PS. I think your idea of including "application callback data" in the argument list for error and warning handlers is good, but I am also hesitant to change that API due to loss of backward compatibility for limited gain. I would also point out that error and warning handler overrides via TIFFSetErrorHandler() and TIFFSetWarningHandler() are global, and not specific to a particular TIFF file structure. This makes application callback data a bit pointless, since there can only be one error and warning handler installed at a time anyways.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda@home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent