Received: by whizzer.wpd.sgi.com (/911001.SGI)
	 id AA03293; Thu, 17 Mar 94 03:00:15 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA03286; Wed, 16 Mar 94 19:00:12 -0800
Received: from Jade.BC.net by sgi.sgi.com via SMTP (931110.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA21255; Wed, 16 Mar 94 19:00:07 -0800
Received: from mail.creo.bc.ca ([192.197.216.2]) by BC.net (4.1/SMI-4.1)
	id AA04208; Wed, 16 Mar 94 18:52:14 PST
Received: from cc:Mail by mail.creo.bc.ca
	id AA763872970 Wed, 16 Mar 94 18:56:10 PST
Date: Wed, 16 Mar 94 18:56:10 PST
From: dhylands@creo.bc.ca
Message-Id: <9402167638.AA763872970@mail.creo.bc.ca>
To: tiff@sgi.sgi.com
Subject: I believe that I've found a bug in tif_write.c
Sender: tiff-owner@sgi.sgi.com

     The function TIFFWriteTile passes "(tsize_t) -1" as the last parameter 
     to the call TIFFWriteEncodedTile. When tsize_t was declared to be a 
     uint32 this would be a very large positve number, however, since 
     tsize_t has been redeclared as an int32, it is now a negative number.
     
     TIFFWriteEncodedTile has the following test:
     
     if (cc > tif->tif_tilesize)
        cc = tif->tif_tilesize;
     
     This of course does nothing when cc == -1.
     
     The "clamp" test should also test for negative numbers, or 
     TIFFWriteTile should pass an appropriate large positive number.
     
     I noticed this when trying to use tiffcp to convert a strip based file 
     to a tile based file. The routine ran and produced a TIFF file with no 
     image data.
     
Dave Hylands      Email: (dhylands@creo.bc.ca)      3700 Gilmore Way
Software Analyst    Tel: (604) 451-2700 (ext. 329)  Burnaby B.C. (Canada)
CREO Products Inc.  Fax: (604) 437-9891             V5G 4M1



