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