Received: from sgi.sgi.com (192.48.153.1) by cerious.com
 with SMTP (Apple Internet Mail Server 1.1.1); Thu, 27 Feb 1997 02:00:41 -0500
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA25102; Wed, 26 Feb 1997 22:53:24 -0800
Received: (from daemon@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA06764 for tiff-list; Wed, 26 Feb 1997 18:34:22 GMT
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA06744 for <tiff-relay@relay.engr.sgi.com>; Wed, 26 Feb 1997 10:34:19 -0800
Received: from hyla.chez.sgi.com ([155.11.194.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02075 for <tiff@sgi.com>; Wed, 26 Feb 1997 10:34:17 -0800
Received: from localhost by hyla.chez.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI)
	 id JAA28763; Wed, 26 Feb 1997 09:52:10 -0800
Message-Id: <199702261752.JAA28763@hyla.chez.sgi.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: ran@adc.com (Rob Nielsen)
Subject: Re: Group 4 read error fix... 
Cc: tiff@sgi.com
Reply-To: Sam Leffler <sam@relay.engr.SGI.COM>
In-reply-to: Your message of "Mon, 24 Feb 1997 14:32:11 CST."
             <199702242032.OAA10747@summit.adc.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 26 Feb 1997 09:52:10 -0800
From: Sam Leffler <sam@hyla.chez.sgi.com>
Sender: owner-tiff@relay.engr.SGI.COM
Precedence: bulk
Status: R

    To:  sam@cthulhu.engr.sgi.com
    Subject:  Re: Group 4 read error fix...
    Date: Mon, 24 Feb 1997 14:32:11 CST
    From:  ran@adc.com (Rob Nielsen)

    
    --7b4d_5eed-6b88_52bc-6e86_e6e
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Content-MD5: b/Tz0G0EJOq2ch2pOB5b0Q==
    X-Sun-Data-Type: text
    
    
    > 
    >     Hi,
    >     
    >     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).
    >     
    >     Anyway here's the diff output of tif_read.c from 
tiff-v3.4beta035-tar.gz
    >     
    >     Rob
    >     
    >     ----- Begin Included Message -----
    >     
    >     
    >     *** tif_read.c.orig     Mon Feb 10 13:42:53 1997
    >     --- tif_read.c  Fri Feb 21 14:40:59 1997
    >     ***************
    >     *** 253,260 ****
    >                              */
    >                             TIFFError(module, "%s: Read error on strip 
%lu",
    >                                 tif->tif_name, (u_long) strip);
    >     !                       tif->tif_curstrip = NOSTRIP;
    >     !                       return (0);
    >                     }
    >                     tif->tif_rawdatasize = bytecount;
    >                     tif->tif_rawdata = tif->tif_base + td->
    > td_stripoffset[strip];
    >     --- 253,262 ----
    >                              */
    >                             TIFFError(module, "%s: Read error on strip 
%lu",
    >                                 tif->tif_name, (u_long) strip);
    >     ! 
    >     !                         bytecount = tif->tif_size - td->
    > td_stripoffset[strip];
    >     !                         td->td_stripbytecount[strip] = bytecount;
    >     !                           
    >                     }
    >                     tif->tif_rawdatasize = bytecount;
    >                     tif->tif_rawdata = tif->tif_base + td->
    > td_stripoffset[strip];
    >     
    > Please send me a sample image (uuencoded, hopefully small) that triggers
    > the problem you are seeing.
    > 
    
    Sam,
    
    I hope this isn't too big.
    
	<...image deleted...>

[NB: I've cc'd the mailing list]

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?

        Sam


