Received: by cthulhu.engr.sgi.com (940816.SGI.8.6.9/911001.SGI)
	for tiff-list id MAA01264; Fri, 21 Oct 1994 12:15:43 -0700
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (940816.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id MAA01242; Fri, 21 Oct 1994 12:15:35 -0700
Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (940627.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.sgi.com> id MAA23068; Fri, 21 Oct 1994 12:15:31 -0700
Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI)
	 id MAA07963; Fri, 21 Oct 1994 12:15:27 -0700
Received: from flake.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI)
	for @sgihub.corp.sgi.com:griffin@sur1a.hpsc.hisd.harris.com id AA19931; Fri, 21 Oct 94 12:15:24 -0700
Received: by flake.asd.sgi.com via SMTP (931110.SGI/911001.SGI)
	for @giraffe.asd.sgi.com:tiff@sgi.sgi.com id AA14370; Fri, 21 Oct 94 12:13:41 -0700
Message-Id: <9410211913.AA14370@flake.asd.sgi.com>
To: griffin@sur1a.hpsc.hisd.harris.com (Ben Griffin)
Cc: tiff@sgi.sgi.com
Subject: Re: Problems catching write errors in tiff library (v3.3beta021) 
In-Reply-To: Your message of "Fri, 21 Oct 1994 11:50:24 EDT."
             <9410211550.AA07338@ sur1a.hpsc.hisd.harris.com> 
Date: Fri, 21 Oct 1994 12:13:40 PDT
From: Sam Leffler <sam@flake.asd.sgi.com>
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

    To:  tiff@sgi.sgi.com
    Subject:  Problems catching write errors in tiff library (v3.3beta021)
    Date: Fri, 21 Oct 1994 11:50:24 EDT
    From:  griffin@sur1a.hpsc.hisd.harris.com (Ben Griffin)

    Version: 3.3beta021  Host: Sparc Solaris 2.3  
    
    There seems to have an incongruity in the return types of the tiff_encoderow
    functions as follows.  
    
       TIFFNoRowEncode returns -1 on failure.
       DumpModeEncode  returns -1 on failure.
       Fax3Encode      returns  0 on failure.
       Fax4Encode      returns  0 on failure.
       LZWEncode       returns  0 on failure.
       PackBitsEncode  returns -1 on failure.
      
    This can cause TIFFWriteScanLine to return a non -1 value (0) which
    does not indicate an error.  I discovered this after running disk full
    tests with our app which uses the tiff library.
    I guess you are safe if you check for a success return value (1) from
    TIFFWriteScanLine, but I happend to be checking for the failure which
    is -1 according to the man page (I guess that is why it's beta eh?).
    
    The fix (kludge) I put in tif_write to aleviate this is:
    line 155:  (second to last line in TIFFWriteScanLine)
      if ( status == 0 ) status = -1;

I wouldn't do this.  There's some trickiness that's evolved over time
regarding error returns from the various encoders.  The issue is that
a single return value is insufficient to indicate whether a decoding
failure is recoverable or not.  For example, when a request to decode
a scanline of G3-encoded data fails, but the decoder is able to resync
at the EOL code then the caller is likely to want to continue.  I think
the right answer is here is to change the caller to look for !success
rather than failure (i.e. -1).  This is definitely an area of the
manual pages that's lacking.
    
    
    Other areas that could cause uncaught errors:
    
       o TIFFClose should return an error value. 
         Now it only a void, but a TIFFFlushData can happen during the call
         so it should return the results of that.
    
         I'm not sure if it is ok to assume that -1 is failure from TIFFCloseFile()
         since that might not always be the unix close command.

This is a big hole.  If TIFFClose returns -1, then what does it mean?
Is the file closed?  What state are things in?  If you really want to
be 100% certain of the state of the image data then you need to do a
flush by hand (it's ok since TIFFClose won't redo the work).  I think
that simply returning an error is insufficient unless the caller can
identify what went wrong.
    
       o In tif_fax3.h the Fax3FlushBits macro calls TIFFFlushData1
         without checking return value. Then each function that uses Fax3FlushBits
         should return a value.

Thanks.

    On another subject, there was some talk earlier about rewriting
    the tiff library in C++.  Any progress on this?  Want any help ?
    
This is unlikely to happen anytime soon.

    Sam



