Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!decwrl!uunet!sco!seanf From: seanf@sco.COM (Sean Fagan) Newsgroups: comp.unix.internals Subject: Re: abort may return (was: Re: Checking Exit Codes) Message-ID: <8554@scolex.sco.COM> Date: 3 Nov 90 07:43:58 GMT References: <18647@rpp386.cactus.org> <4057@awdprime.UUCP> <18658@rpp386.cactus.org> <8508@scolex.sco.COM> <18665@rpp386.cactus.org> Sender: news@sco.COM Reply-To: seanf (Sean Fagan) Followup-To: comp.lang.c Organization: The Santa Cruz Operation, Inc. Lines: 49 In article <18665@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >i checked my 1988 X3J11 draft and it was silent - Section 4.2.1.1 #include void assert(int expression); The assert macro puts diagnostics into programs. [...] It then calls the abort function. Section 4.10.4.1 #include void abort(void); The abort function causes abnormal program termination to occur, unless the signal SIGABRT is being caught and the signal handler does not return. December 7 1988 X3J11. Seems to say quite a bit on it. First of all, you cannot check the return value of assert() or abort(), since both are void's. Second, even if you catch or ignore SIGABRT, the implementation is required to exit, still (it seems). (In that respect, SCO's is wrong, I just found out...) >% uname -s >XENIX Repeat after me, john. SCO also sells UNIX. Repeat it a hundred times. Since that's what I'd been working on for about 1.5 years, that's what I was talking about. >a conforming implementation might be > kill (getpid (), SIGABRT); Nope. raise(SIGABRT). It's still possible to get it to fail: a function set up via atexit() could simply longjmp back to main (*shudder*!). Followup's to c.l.c, ok? -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.