Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals
Subject: abort may return (was: Re: Checking Exit Codes)
Message-ID: <18665@rpp386.cactus.org>
Date: 1 Nov 90 01:06:46 GMT
References: <18647@rpp386.cactus.org> <4057@awdprime.UUCP> <18658@rpp386.cactus.org> <8508@scolex.sco.COM>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 63
X-Clever-Slogan: Recycle or Die.

In article <8508@scolex.sco.COM> seanf (Sean Fagan) writes:
>In article <18658@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>>so, you will always assume that failing asserts never return?  
>
>Yes.  I believe that's what ANSI (and POSIX) says.

i checked my 1988 X3J11 draft and it was silent - the only documentation
i found supporting the claim that abort never returns was in XPG3.  still,
the point is simply that to maximize portability you always assume the
worst.  posix just says to do whatever ANSI C says to do.

>                                                    At least one
>implementation (ours, to be honest 8-)) makes sure that abort() will not
>return.  The only way, from my glancing of the object code (disassembled, of
>course), to get it to return would be to send the process a signal it *does*
>catch, and then longjmp() out of that signal handler.

sigh.

% uname -s
XENIX

this =is= SCO's implementation.  perhaps the newer versions work the
way you say, but just saying "we don't do it" isn't clear enough - and
again points to how unreliable the statement is.

i checked my System III-derived microsoft xenix machine also this
morning, and the assert macro doesn't even call abort - it just calls
exit() and gets it over and done with ;-(.

>But there's now way I know of to make sure that such a thing doesn't happen.
>(Well, you could, in abort(), block all signals, I suppose, and, now that I
>think about it, I think I'll see about getting us to do so 8-).)

the normal trick is to set SIGIOT to SIG_DFL, which prevents the signal
handler from ever catching SIGIOT.  this isn't all that far-fetched as
other library routines catch certain signals, dork around a bit, then
re-send the same signal they just caught.

a conforming implementation might be

void 
abort (void)
{
	signal (SIGABRT, SIG_DFL);
	kill (getpid (), SIGABRT);
	exit (1);
}

i believe the old-time implementation was something to the effect of

int
abort ()
{
	return kill (getpid (), SIGABRT);
}

which is why the problems come up.
-- 
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