2005.12.11 12:44 "[Tiff] [PATCH] LynxOS compile fixes", by Olli Savia

2005.12.13 21:11 "RE: [Tiff] Bug in tiffcp (unsupported codecs return 0)", by Jason Frank

Thanks, I'll get it built today and test it out in the morning. I can always unlink it myself. I'm just wondering what the advantage is in leaving the file around, taking up disk space, when it doesn't do any good for anyone. I can see leaving it around for forensics, of course. I'm really just thinking out loud.

What file did you make the change in?

Jason

-----Original Message-----

From: tiff-bounces@lists.maptools.org [mailto:tiff-bounces@lists.maptools.org] On Behalf Of Andrey Kiselev Sent: Tuesday, December 13, 2005 2:09 PM To: tiff@lists.maptools.org

Subject: Re: [Tiff] Bug in tiffcp (unsupported codecs return 0)

On Tue, Dec 13, 2005 at 01:53:49PM -0600, Frank, Jason wrote:

>
> --- ../tiff-3.7.4-orig/tools/tiffcp.c 2005-07-08 04:03:49.000000000
> -0500

> +++ tools/tiffcp.c      2005-12-13 10:45:23.000000000 -0600

> @@ -852,8 +852,10 @@
> for (s = 0; s < ns; s++) {
> tsize_t cc = (row + rowsperstrip >
> imagelength)?
> TIFFVStripSize(in, imagelength - row):
> stripsize;
> - if (TIFFReadEncodedStrip(in, s, buf, cc) < 0
&&
> !ignore)
> - break;

> +                       if (TIFFReadEncodedStrip(in, s, buf, cc) < 0 
> + &&
> !ignore) {
> +                         _TIFFfree(buf);
> +                         return FALSE;
> +                       }
>                         if (TIFFWriteEncodedStrip(out, s, buf, cc) < 

> 0) {
> _TIFFfree(buf);
> return (FALSE);
>

> This same issue appears to be present in all of the cpFunc's, athough > they're all coded slightly differently. I suppose we could have to do

> that to all the cpFuncs (and possibly some others...)
>
> I'm worried that this is not the correct fix. Can someone tell me if
> I'm barking up the right tree?

Jason,

I have fixed this issue today. Please, try the latest CVS snapshot and report results, if something will be wrong.

> Also, I've noticed that when this happens, we do not unlink the new > TIF that we're creating (assuming that we're not appending.) That's a

> pretty easy fix. Any interest in doing that?

Well, I don't want to unlink the broken file. Does it really needed?