> Date: Tue, 8 Apr 1997 14:55:40 GMT
> From: christos@nyc.deshaw.com (Christos Zoulas)

> >Perhaps what we need is a gcc extension so we can write something like
> >
> >	void (*sv_handler)(__oldstyle__);
> >
> >that satisfies -Wmissing-prototypes -Wstrict-prototypes but otherwise
> >has the semantics of an old-style argument list declaration.
> 
> That was me. I'll address that shortly because I've ran into this one
> time too many lately.
> 
> christos

My recollection is that the POSIX 1003.1b spec. (the first one that 
includes real-time signals extensions) specifies to forms for this:
(I would quote, but my P1003.1b has grown legs...)

	void (*sa_handler)(int);
	void (*sa_sigaction)(int, siginfo_t *, void *);

Most vendors imlement this as a union, and arrange for the signal
trampoline to call the function with three args no matter what.
Then the function pointer can be a union, like this: (Solaris)

/*
 * The signal handler routine can have either one or three arguments.
 * Existing C code has used either form so not specifing the arguments
 * neatly finesses the problem.  C++ doesn't accept this.  To C++
 * "(*sa_handler)()" indicates a routine with no arguments (ANSI C would
 * specify this as "(*sa_handler)(void)").  One or the other form must be
 * used for C++ and the only logical choice is "(*sa_handler)(int)" to allow
 * the SIG_* defines to work.  "(*sa_sigaction)(int, siginfo_t *, void *)"
 * can be used for the three argument form.
 */
struct sigaction {
	int sa_flags;
	union {
#ifdef	__cplusplus
		void (*_handler)(int);
#else
		void (*_handler)();
#endif
		void (*_sigaction)(int, siginfo_t *, void *);
	}	_funcptr;
	sigset_t sa_mask;
	int sa_resv[2];
};
#define	sa_handler	_funcptr._handler
#define	sa_sigaction	_funcptr._sigaction