Date: Fri, 26 Apr 1996 23:55:00 GMT From: James Raynard <jraynard@dial.pipex.com> To: bde@zeta.org.au Cc: bde@zeta.org.au, freebsd-hackers@freebsd.org Subject: Re: Flaws in system() implementation? Message-ID: <199604262355.XAA01765@dial.pipex.com> In-Reply-To: <199604250135.LAA31600@godzilla.zeta.org.au> (message from Bruce Evans on Thu, 25 Apr 1996 11:35:03 %2B1000)
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604262355.XAA01765>