Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.unix-wizards,net.lang.c
Subject: ANSI X3J11 onexit() implementation
Message-ID: <1438@brl-smoke.ARPA>
Date: Tue, 17-Jun-86 17:10:44 EDT
Article-I.D.: brl-smok.1438
Posted: Tue Jun 17 17:10:44 1986
Date-Received: Sat, 21-Jun-86 09:18:20 EDT
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29
Keywords: X3J11 onexit freebie
Xref: watmath net.unix-wizards:18512 net.lang.c:9506

I have just posted a public-domain implementation of the ANSI X3J11
(draft C language standard) "onexit" function to net.lang.c (INFO-C),
as I promised during the last couple of weeks.  The main purpose is
to help implementors who thought that this would be too much trouble
and were therefore objecting to onexit().

As a result of actually implementing this function, I am now in a
position to criticize the interface.  In the May 1, 1986 Draft
standard (X3J11/86-074), the new defined type "onexit_t" is used in
two different contexts: as the return value type of the user's
pre-termination function and as the value returned by onexit() to
indicate success or failure of function registration.  The former
usage should certainly be (void), since there is no way to make use
of any value that a pre-termination function might return.  The
latter usage need only be a simple (int), but the current Draft
states that it must be comparable to a NULL pointer constant, which
unfortunately the Draft has strongly indicated should be (void *)0
instead of the traditional 0.  A much cleaner interface would be:

	int onexit(void (*func)(void));

which would return zero or not depending on whether the function
was successfully registered.  I think the current awkward design is
an artifact of the original Whitesmiths, Ltd. implementation which
required each pre-termination function to return a pointer to the
next most recently registered function, so that exit() could
traverse the list of function pointers without having to maintain
private storage for them.  However, that's not necessary under the
current design, so I would like to see the interface cleaned up.