From owner-freebsd-hackers Tue Apr 23 16:49:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA19184 for hackers-outgoing; Tue, 23 Apr 1996 16:49:57 -0700 (PDT) Received: from vent.pipex.net (root@vent.pipex.net [158.43.128.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA19166 for ; Tue, 23 Apr 1996 16:49:52 -0700 (PDT) Received: from dial.pipex.com by vent.pipex.net (8.6.12/PIPEX simple 1.20) id AAA16690; Wed, 24 Apr 1996 00:49:33 +0100 Received: (from jraynard@localhost) by dial.pipex.com (8.6.12/8.6.12) id AAA02030; Wed, 24 Apr 1996 00:20:25 GMT Date: Wed, 24 Apr 1996 00:20:25 GMT From: James Raynard Message-Id: <199604240020.AAA02030@dial.pipex.com> To: bde@zeta.org.au CC: freebsd-hackers@freebsd.org In-reply-to: <199604231231.WAA20624@godzilla.zeta.org.au> (message from Bruce Evans on Tue, 23 Apr 1996 22:31:20 +1000) Subject: Re: Flaws in system() implementation? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> Bruce Evans writes: > > >2. Use of the soon-to-be-obsolescent vfork() instead of fork(). > > Reports of its death seem to be premature :-). I actually meant to type "soon-to-be-obsolete", but maybe what I put is more appropriate. 8-) > More points: > > 5. Use of the crufty signal() and deprecated sigblock() and sigsetmask() > instead of POSIX signal handling interfaces. It isn't clear whether the > sa_mask and sa_flags used by signal() give the correct behaviour. Yes, I thought about this but thought it best to try and avoid too many changes to the original code. Actually I was thinking about a "project" that I can do on 2.1.0-R code (I don't think I can afford the phone bills involved in running -current) and trying to make things like signal-handling in libc more Posix-compliant seems like a good one to start with. Any objections and/or pitfalls if I do this? > 6. Missing EINTR handling for waitpid(). This might be OK if SA_RESTART > was forced, but see point 5 - it is now clear that the sa_flags used by > signal() don't give the correct behaviour if the application has used > siginterrupt() to change the default of SA_RESTART. Hmm, didn't see that one, but now you mention it... > Some of these points also apply to popen/pclose, but the FreeBSD already > seems to be correct although unnecessarily unportable. E.g., it handles > EINTR. Out of interest, why does handling EINTR make it unportable? Cheers James