From owner-freebsd-hackers Mon Apr 13 12:50:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04142 for freebsd-hackers-outgoing; Mon, 13 Apr 1998 12:50:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-59.waterford.indigo.ie [194.125.139.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04060 for ; Mon, 13 Apr 1998 19:49:55 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id UAA07048; Mon, 13 Apr 1998 20:49:58 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804131949.UAA07048@indigo.ie> Date: Mon, 13 Apr 1998 20:49:57 +0000 In-Reply-To: James Raynard "Re: PR kern/1144" (Apr 13, 4:06pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: James Raynard , rotel@indigo.ie Subject: Re: PR kern/1144 Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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