Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ginosko!aplcen!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: type of signal functions (was Abandon NULL for (0))
Message-ID: <20134@mimsy.UUCP>
Date: 12 Oct 89 17:39:45 GMT
References: <252B5E41.1244@marob.masa.com> <19999@mimsy.UUCP> <740@geovision.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

>In article <19999@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>	void (*signal(int, void (*)(int)))(int);

In article <740@geovision.UUCP> pt@geovision.uucp (Paul Tomblin) writes:
>For some strange reason, our VMS C compiler has the following in signal.h:
>
>int (*signal (int sig, void (*func)(int, ...)) ) (int, ...);
>
>which seems slightly contradictory. ... Someone care to comment on why
>Dec did it this way, and if they are planning to fix it later?

Well, aside from the `int' at the front (which is of course entirely
incompatible with the `void' in the middle), the only difference is the
`, ...', which (on VMS and Unix VAXen, among others) makes no actual
difference in function-call mechanism.  What it does do, however, is
allow one to write

	void int_handler(int sig, int code, struct sigcontext *scp) {
		... SIGINT handling code ...
	}

as on 4BSD.  No doubt VMS also passes at least a `code' argument, so
that you can tell different kinds of floating-point exceptions apart.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris