From owner-freebsd-hackers  Mon Jul  1 01:22:48 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA09738
          for hackers-outgoing; Mon, 1 Jul 1996 01:22:48 -0700 (PDT)
Received: from aphrodite.funet.fi (root@[193.166.1.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA09676
          for <hackers@freebsd.org>; Mon, 1 Jul 1996 01:21:21 -0700 (PDT)
Received: (from jau@localhost) by aphrodite.funet.fi (8.7.4/8.6.12+CSC-2.1) id LAA24412; Mon, 1 Jul 1996 11:18:09 +0300 (EET DST)
From: Jukka Antero Ukkonen <jau@aphrodite.funet.fi>
Message-Id: <199607010818.LAA24412@aphrodite.funet.fi>
Subject: Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD...
To: bde@zeta.org.au (Bruce Evans)
Date: Mon, 1 Jul 1996 11:18:09 +0300 (EET DST)
Cc: terry@lambert.org, bde@zeta.org.au, hackers@freebsd.org
In-Reply-To: <199606290650.QAA27894@godzilla.zeta.org.au> from "Bruce Evans" at Jun 29, 96 04:50:04 pm
Latin-Date: Lunti I Iulie a.d. MCMXCVI
Organization: FUNET/CSC
Phone: +358-0-6215280 (home)
Content-Conversion: prohibited
X-Mailer: ELM [version 2.4 PL25+pgp]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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