Checking Exit Codes (was: Re: Trojan Horses)

Jim Balter jim at segue.segue.com
Wed Oct 31 21:29:07 AEST 1990


In article <18658 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>you could take the easy way out, listen to
>your uncle fred, and just put an exit after failing assert()
>calls.  this is easy, portable, and foolproof.  it has the novel
>property that it always works.

You could avoid some embarrassment by testing your claims before making them
public.  It would appear that you've never actually used assert, or that when
you do you don't follow the practice you recommend.  The only way to achieve
what you suggest is

	assert(condition); if ( !condition ) exit(1);

Of course, only a fool would code this way to account for the possibility
that SIGABORT is being caught and the signal routine returns.  Such a SIGABORT
handler is a coding error; adding a firewall to "guard" against that coding
error, especially after a failed assert, is idiotic.  Given that you were lucky
enough to get to the assert in the first place, who the hell cares what happens
after the assert?  The assert means that the program is in an unexpected,
undefined, unpredictable state.

Then again, perhaps I can bump my code production for the code line counters
and improve my code robustness at the same time by adding the following every
few lines:

	assert(0 == 0); /* check that compiler is still working */
	if ( 0 != 0 )
	{
		abort();	/* in case assert didn't call abort */
		exit(1);	/* in case abort returned */
		printf("exit returned unexpectedly\n");
				/* perhaps the library exit routine has been
				   overridden with a routine that returns;
				   here we follow the pseudo-wizardly principle
				   that all errors must be reported to the user
				 */
		/* etc. */
	}



More information about the Comp.unix.internals mailing list