Received: by cthulhu.engr.sgi.com (940816.SGI.8.6.9/911001.SGI)
	for tiff-list id LAA24429; Fri, 21 Oct 1994 11:32:14 -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 LAA24419; Fri, 21 Oct 1994 11:32:08 -0700
Received: from firewall.island.com by sgi.sgi.com via ESMTP (940627.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.com> id LAA13567; Fri, 21 Oct 1994 11:32:06 -0700
Received: (from daemon@localhost) by firewall.island.com (8.6.9/8.6.9) id LAA17716 for <tiff@sgi.com>; Fri, 21 Oct 1994 11:32:43 -0700
Received: from island.island.com(199.4.83.1) by firewall via smap (V1.3mjr)
	id sma017714; Fri Oct 21 11:31:54 1994
Received: from kismet. by island.com (5.0/SMI-SVR4)
	id AA01362; Fri, 21 Oct 1994 11:31:14 +0800
Received: by kismet. (5.0/SMI-SVR4)
	id AA09925; Fri, 21 Oct 1994 11:20:31 +0800
Date: Fri, 21 Oct 1994 11:20:31 +0800
From: rtm@island.com (Richard Minner)
Message-Id: <9410211820.AA09925@kismet.>
To: tiff@sgi.sgi.com
Subject: Re: Problems catching write errors in tiff library (v3.3beta021)
X-Sun-Charset: US-ASCII
Content-Length: 0
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

> 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?).

Just an aside, this is why it is a good idea to test for specifically
documented codes that you care about, and treat _all_ other values
as "failure".  That is, if the function returns an undocumented value
should you assume everything is ok?  I wouldn't :-)  At the very least
the situation demands investigation.  For simplest code this means
testing for the specifically documented _success_ code(s), not the
failure code(s), i.e. !knownSuccess ==> failure (of some sort).
I cringe every time I see
	if (somesyscall() != -1)
	{
		//code assuming success
	}

Many functions fail to define the meaning of most codes, saying
something like:
	returns 0 on success, -1 on failure.
Left implied as that all other values are "unspecified" or "reserved
for future use".  A full test would look like
	if (ret == 0)		... // success
	else if (ret == -1)	... // documented failure
	else			... // unspecified/unknown

Unspecified codes _can_ be handled as "warn and assume ok" if such
is your leaning, but I suggest treating them as failures.

(The new bool type in "Standard C++" will simplify some of these
interfaces, incidentally -- only two possible values! :-)
--
Richard Minner  rtm@island.com
Island Graphics Corporation
Sacramento, California

