Date: Mon, 1 Jul 1996 11:18:09 +0300 (EET DST) From: Jukka Antero Ukkonen <jau@aphrodite.funet.fi> To: bde@zeta.org.au (Bruce Evans) Cc: terry@lambert.org, bde@zeta.org.au, hackers@freebsd.org Subject: Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... Message-ID: <199607010818.LAA24412@aphrodite.funet.fi> In-Reply-To: <199606290650.QAA27894@godzilla.zeta.org.au> from "Bruce Evans" at Jun 29, 96 04:50:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Bruce Evans:
>
> >/*
> > * Signal vector "template" used in sigaction call.
> > */
> >struct sigaction {
> > union {
> > /*
> > * These two could be separate fields quite as well.
> > *
> > * Either a simple POSIX.1 signal handler
> > * with additional BSD style parameters ...
> > */
> > void (*sa_handler) _P((int, ...));
> > /*
> > * ... or a more complex POSIX.4 signal handler
> > */
> > void (*sa_sigaction) _P((int, siginfo_t *, void *));
> > };
>
> How can POSIX.4 specify this? It is incompatible with the POSIX.1
> struct sigaction (as is the varargs sa_handler).
I do not think that is really the case. You can still refer to
sa.sa_handler just as before and it's positioning within the
struct can remain unchanged.
Oops. Don't bother too much with the variable ... arguments
in the sa_handler field. The code above was extracted from the
header files belonging to my personal C library, which in some
cases may be a bit unorthodox beast.
My C library has a rather relaxed attitude towards all kinds of
BSD style and other extensions. It is a sort of "everything and
then some" implementation. Those dots were put there just to keep
the compiler quiet when I needed the BSD style extended argument
list. They don't break anything really, but for reasons of strict
POSIX portability one should of course envelope that within
#ifdef _POSIX_SOURCE or something.
> The user sigismember() is more or less required to check the bounds, so
> it needs to be larger and uglier. The kernel should probably check `sig'
> in advance and then use special kernel versions of the signal manipulation
> functions.
Right - the kernel should check that the signal code is within
the range of known signals. It should be done almost the first
thing at the beginning of the system calls that deal with the
signals. It would be much more of an effort if the macros were
really changed to check the range every time they are used.
Cheers,
// jau
------
/ Jukka A. Ukkonen, FUNET / Centre for Scientific Computing
/__ M.Sc. (sw-eng & cs) Tel: (Home) +358-0-6215280
/ Internet: ukkonen@csc.fi (Work) +358-0-4573208
v Internet: jau@funet.fi (Mobile) +358-400-606671
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607010818.LAA24412>