From owner-freebsd-hackers Fri Apr 26 17:46:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA14609 for hackers-outgoing; Fri, 26 Apr 1996 17:46:51 -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 RAA14598 for ; Fri, 26 Apr 1996 17:46:47 -0700 (PDT) Received: from dial.pipex.com by vent.pipex.net (8.6.12/PIPEX simple 1.20) id BAA05925; Sat, 27 Apr 1996 01:46:37 +0100 Received: (from jraynard@localhost) by dial.pipex.com (8.6.12/8.6.12) id XAA01765; Fri, 26 Apr 1996 23:55:00 GMT Date: Fri, 26 Apr 1996 23:55:00 GMT From: James Raynard Message-Id: <199604262355.XAA01765@dial.pipex.com> To: bde@zeta.org.au CC: bde@zeta.org.au, freebsd-hackers@freebsd.org In-reply-to: <199604250135.LAA31600@godzilla.zeta.org.au> (message from Bruce Evans on Thu, 25 Apr 1996 11:35:03 +1000) Subject: Re: Flaws in system() implementation? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >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? > > Keep up with -current enough to avoid re-doing things (unless you're > just doing them for educational purposes). I just checked the NetBSD Doing this certainly would be educational, but it would be nice if it could be useful to the FreeBSD project (giving something back and all that). I may yet give -current a shot, if I can get my system backed up properly... > version and found that -current would already have your changes if it > kept up with NetBSD :-). The NetBSD version also replaces execl() by > execve(), presumably to save a few cycles. To be honest, I was surprised no-one had thought of (or should that be got round to ?) it before. > >> 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? > > I meant that handling EINTR helped make it correct. The old signal > handling functions make it unportable. OK, I see what you mean now. Sorry for the misunderstanding. James -- James Raynard, Edinburgh, Scotland mail: jraynard@dial.pipex.com