Message-ID: 397C6550.4BBE4850@home.com
To: morourke@adobe.com
Subject: TIFF Error handler
From: Frank Warmerdam <warmerda@home.com>
Date: Mon, 24 Jul 2000 11:48:32 -0400
CC: TIFF Mailing List <tiff@olympiakos.com>
Sender: owner-tiff@olympiakos.com


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

