Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!umd5!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Any way to catch exit()?
Message-ID: <8399@smoke.ARPA>
Date: 31 Aug 88 10:02:08 GMT
References: <8808261432.AA11635@ucbvax.Berkeley.EDU> <388@infmx.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <388@infmx.UUCP> greggy@infmx.UUCP (greg yachuk) writes:
>Microsoft C defines a function `onexit()' ...
>The MSC 5.0 manual also states that there is a similar ANSI-standard
>functions named `atexit()'.  I don't know anything about it.

onexit() originated with Whitesmiths, Ltd.  Somewhere in the course
of developing the proposed ANSI C standard, a similar but incompatible
function of the same name was present for several drafts.  However,
it was possible to take the revised onexit() and substantially simplify
the interface, and so we did.  I suggested calling the result atexit()
so that Whitesmiths customers would not find their use of onexit()
broken.  Unfortunately, IBM and Microsoft jumped the gun and added the
interim version of onexit() to their C implementations.  Not only is it
incompatible with the original Whitesmiths version, it isn't the
function finally adopted by X3J11 for this purpose.  (At least it is
possible to implement both simultaneously!)

Incidentally, there are still some unintended ambiguities in the
specification of atexit(), but (as I recall; my notes are not at hand)
the Committee was unwilling to tighten up the spec at this point.  The
main ambiguity is that an exit handler SHOULD be unregistered before
it is invoked, so that a reentry to exit() from an exit handler will
not cause an infinite recursion, but we hadn't thought of that until
a member of the public pointed it out.  I hope that implementors will
be careful to do this.  Perhaps I should update my public-domain
implementation and repost it.