Path: utzoo!attcan!uunet!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals
Subject: Checking Exit Codes (was: Re: Trojan Horses)
Message-ID: <18647@rpp386.cactus.org>
Date: 26 Oct 90 12:51:19 GMT
References: <1885@necisa.ho.necisa.oz> <5238:Oct2322:14:3690@kramden.acf.nyu.edu> <1893@necisa.ho.necisa.oz> <8645:Oct2521:49:5790@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 27
X-Clever-Slogan: Recycle or Die.

In article <8645:Oct2521:49:5790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1893@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes:
>> Surely you mean that if you don't know how to handle a specific recovery
>> (for some unspecified error type) it's still treated as failure?
>
>Not at all. This might be true for calls that give me information, but
>close() is not such a call. Do you check the return value of assert()?

Sure, why not.  You do know that assert() is documented as returning
to the invoker?  You have to read the abort() page to find this out,
but coding

	assert (some impossible condition);
	function (! some impossible condition allowed);

is naive in non-user code.  What is going to happen one day when the
user does

	for (i = 1;i < NSIG;i++)
		(void) signal (i, SIG_IGN);

You better start checking the return code for assert() as well.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson