From owner-freebsd-hackers  Mon Jun 17 21:49:30 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA25959
          for hackers-outgoing; Mon, 17 Jun 1996 21:49:30 -0700 (PDT)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA25954
          for <hackers@freebsd.org>; Mon, 17 Jun 1996 21:49:28 -0700 (PDT)
Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id VAA06907; Mon, 17 Jun 1996 21:49:26 -0700
Date: Mon, 17 Jun 1996 21:49:26 -0700
From: Sean Eric Fagan <sef@kithrup.com>
Message-Id: <199606180449.VAA06907@kithrup.com>
To: michaelh@cet.co.jp, smpatel@umiacs.umd.edu
Subject: Re: vfork cow?
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>1-  Many old programs use vfork()'s "feature" of allowing the child access
>	to the parent's address space.  While it's plain wrong for a
>	program to exploit this side-effect of vfork(), it's already done
>	(and hard to undo).

Any such program will not work under FreeBSD, because it doesn't do this!

Also, I don't think "many" programs ever depended on this.  csh did, and it
was fixed a long time ago.  (The fact that the 4.2 allowed the child process
to modify its parent's memory was a bug, and was listed as such in the
manpage.)

Sean.