LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
October 1994
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1994.10.21 18:53 "Re: Problems catching write errors in tiff library (v3.3beta021)", by John Bradley1994.10.21 18:32 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Richard Minner
> 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