1997.02.26 17:52 "Re: Group 4 read error fix...", by Sam Leffler
We have a whole bunch of group 4 files that libtiff was having problems reading. These same files were viewable with PreView and other tiff viewers (Vax based).
Your image is malformed; either the value of the StripByteCounts tag is wrong or there is image data missing from the file. Your change alters the behaviour of the library (in one case of many) to continue processing image data even though a read error occurred (it's a simulated read here as the file data is actually memory-mapped). I'm not sure this is a good thing. If I take your change but don't modify the other cases (e.g. TIFFReadRawTile1 and TIFFReadRawStrip1) then the library will behave differently depending on the API routine used to fetch image data, whether the image data is read using the mmap'd interface or not, and whether or not the image data is encoded. If I modify the other interfaces to be consistent then read errors will not be reported properly since the routines (currently) report either -1 for an error or the number of bytes of data returned to the caller. Changing the existing API to return a short read might clean things up but would potentially hide errors and would require all the clients of the library to change to handle new return cases. Since the original problem was due to a malformed image, I'm tempted to just punt on this.
Comments? Maybe someone wants to try revise the read/write interfaces to clean up all the error conditions that are presently lumped together?