On Apr 8, 11:12am, gwr@mc.com (Gordon W. Ross) wrote:
-- Subject: Re: long long vs. -ansi...

| > 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 *);

That is correct. On the other hand, you'll need to have the `int' argument
in the `c' case too, otherwise the warning will not go away:

| struct sigaction {
| 	int sa_flags;
| 	union {
| 		void (*_handler)(int);
| 		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

This is the easy part; the question is what to do with the legacy 
`struct sigvec'. This needs to be passed:

    void (*sv_handler)(int sig, struct sigcontext *ctx, char *addr);

On the other hand, this is not implemented in most architectures, so my
inclination is to declare it  void(*)(int) and be done with it.

christos