Date: Mon, 13 Apr 1998 20:49:57 +0000 From: Niall Smart <rotel@indigo.ie> To: James Raynard <fhackers@jraynard.demon.co.uk>, rotel@indigo.ie Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PR kern/1144 Message-ID: <199804131949.UAA07048@indigo.ie> In-Reply-To: James Raynard <fhackers@jraynard.demon.co.uk> "Re: PR kern/1144" (Apr 13, 4:06pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 13, 4:06pm, James Raynard wrote:
} Subject: Re: PR kern/1144
> On Mon, Apr 13, 1998 at 01:47:14PM +0000, Niall Smart wrote:
> > The abovementioned PR is for sig{add, del}set and sigismember.
> > Apparently POSIX requires that these functions check that the
> > specified signal number exists, which they currently do not do.
[snip]
> > So should I submit patches to fix this
> > problem by deleting the macro definitions and adding the required
> > checking to /usr/src/lib/libc/gen/sigsetops.c or are we going to
> > ignore POSIX?
>
> The consensus seemed to be that there was no easy way to do it, so
> we've been ignoring POSIX ever since (in that respect at least) :-)
Hrm, is this still the `official' position? It's nice to follow
standards when you can, and I don't see that changing to functions
instead of macro's would cause big, if any problems.
> Incidentally, I've been working on some patches to get around the
> NSIG==32 limit. I've done most of the "boring" work, but there are
> a few things left over that I don't really know enough to handle:
>
> 1. Emacs breaks (albeit an old version - 19.29). Everything else
> I've tried works, including linuxxdoom.
Do you mean an emacs binary compiled when sigset_t typedef'd to unsigned
int, or one compiled with sigset_t typedef'd to u_int64_t?
> 2. I had to add an extra system call osigprocmask for the compat stuff
> which does exactly what the old sigprocmask call used to do. This
> makes upgrading to the new code a real pain.
Why was this necessary? Are you talking about dealing with code
that passes an int* instead of a sigset_t*? Or perhaps you are
talking about code that has already been compiled with sigset_t
typedef'd to int? Can't that be handled in a compatability library
without defining a new system call?
> 3. Could probably do with optimising, as well. Not to mention the usual
> stylistic/code management issues...
>
> Anyone care to help me out?
I don't have a machine with -current, nor do I have commit priveledges,
so I don't know if there is anything I can do -- where is the code
that handles NSIG >= 32 that you have so far?
Regards,
Niall
--
Niall Smart. Microsoft Suck. See www.freebsd.org for details.
echo "#define if(x) if(!(x))" >> /usr/include/stdio.h
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804131949.UAA07048>