From owner-cvs-all  Sat Oct 10 21:20:34 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id VAA12162
          for cvs-all-outgoing; Sat, 10 Oct 1998 21:20:34 -0700 (PDT)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA12151;
          Sat, 10 Oct 1998 21:20:22 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA06194;
	Sun, 11 Oct 1998 14:20:09 +1000
Date: Sun, 11 Oct 1998 14:20:09 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199810110420.OAA06194@godzilla.zeta.org.au>
To: bde@FreeBSD.ORG, peter@netplex.com.au
Subject: Re: cvs commit: src/lib/libc/gen popen.c
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

>>   Modified files:
>>     lib/libc/gen         popen.c 
>>   Log:
>>   vfork -> fork.  The child calls execl() which calls malloc(), so
>>   vfork() can't be used.  We could use alloca() in execl() so that

>Why not fix it properly by not using execl()?

I didn't think of such a simple fix, and it's not urgent.  You still
have to look at the execv(3) sources to see that it doesn't call malloc().
Using execve(2) would be safer.

>fork() is significantly slower than vfork(), especially with a complex 
>address space with lots of maps that fork() has to clone.  It'll all the 
>malloc calls in execl() too.

I know, so I thought fixing /bin/sh was more urgent :-).

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message