In article <199608282011.QAA04390@Collatz.McRCIM.McGill.EDU> mouse@Holo.Rodents.Montreal.QC.CA writes:
>>Description:
>	<signal.h> is missing some prototypes; they cause trouble when
>	code that uses signals is compiled with -Wmissing-prototypes
>	-Wstrict-prototypes.  Specifically, SIG_DFL, SIG_IGN, and
>	SIG_ERR provoke such complaints, as do the sa_handler and
>	sv_handler structure elements.

This is a very thorny issue, that is why it has not been fixed yet.
The difficulty is that we cannot satisfy old and new code. In addition,
the kernel sendsig() functions pass additional arguments after the
signal number which can be useful, and these arguments vary between ports.

Historically the sv_handler member of the sigvec structure passed:

    (int, int, struct sigcontext *, char *)

So if you add the suggested prototypes, old code that passes those
arguments will fail.

I think that eventually we want to move to something like the SVR4
signal passing convention which is:

    (int, siginfo_t *, void *)

Unfortunately prototyping the sa_handler member of struct sigaction
with additional arguments is not legal and one has to resort to hacks
of the form:

struct sigaction {
	union {
		_handler __P((int));
		_action __P((int, siginfo_t *, void *);
	} _hdlr;
	....
};

#define sa_handler	_hdlr._handler
#define sa_action	_hdlr._action

In my opinion programs that use sigvec should be converted to use the
posix interfaces. If we still want to maintain compatibility with sigvec
we could prototype the sigvec sv_handler with the historical four arguments,
but this will just break code that previously compiled without warnings.

The struct sigaction should be changed with something like the above in
the future; for now the 'sa_handler __P((int))' prototype is probably
sufficient.

Feedback and/or corrections appreciated.

christos