- 1994.10.21 03:20 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Richard Minner
- 1994.10.21 05:53 "Re: C++ tiff library", by Richard Minner
- 1994.10.21 17:12 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Dan McCoy
- 1994.10.21 19:13 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Sam Leffler
1994.10.21 03:20 "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