Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!husc6!cmcl2!brl-adm!umd5!cvl!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Re: Assigning to Pointers
Message-ID: <6653@mimsy.UUCP>
Date: Wed, 13-May-87 01:31:43 EDT
Article-I.D.: mimsy.6653
Posted: Wed May 13 01:31:43 1987
Date-Received: Sat, 16-May-87 02:24:46 EDT
References: <3537@vrdxhq.UUCP> <857@killer.UUCP> <6611@mimsy.UUCP> <266@sjoerd.cs.vu.nl>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 58
Xref: mnetor comp.sys.ibm.pc:3995 comp.lang.c:2159

In article <6611@mimsy.UUCP> I wrote some nonsense about signal.
Ignore it.  Thanks to sjoerd@cs.vu.nl (Sjoerd Mullender) for catching
that.

(enter exposition)

I was thinking of a particular sort of `onexit' function, wherein
each function returns a pointer to another function.  Each of these
functions is called until one returns a nil pointer:

	/* from <onexit.h>:
	typedef void (*onexit_t)();
	 * `cheating' */

	onexit_t module_lastexit;
	onexit_t module_cleanup();

	module_setup()
	{
		...
		/* arrange to have module_cleanup called at exit */
		module_lastexit = onexit(module_cleanup);
		/* and remember whatever was registered before us */
	}

	onexit_t
	module_cleanup()
	{
		/* clean up */
		...
		/* and have exit do the previously registered function */
		return (module_lastexit);
	}

Exit then has a loop of the form

		while (doatexit != NULL)
			/* note the odd cast required */
			doatexit = (*(onexit_t *(*)())doatexit)();

and the onexit function itself reads

	onexit_t
	onexit(f)
		onexit_t f;
	{
		onexit_t olddo = doatexit;

		doatexit = f;
		return (olddo);
	}

(exit exposition)

How I got this confused with signal I have no idea.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris