Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!mit-eddie!ll-xn!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <22241@sun.uucp>
Date: Sat, 27-Jun-87 01:44:41 EDT
Article-I.D.: sun.22241
Posted: Sat Jun 27 01:44:41 1987
Date-Received: Sun, 28-Jun-87 01:03:25 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3754@spool.WISC.EDU>
Sender: news@sun.uucp
Lines: 46

> but I believe vfork() was implemented *specifically* for csh.

"vfork" was implemented for the benefit of various programs, "csh"
among them.  However, the fact that the current implementations of
"vfork" give you a limited form of shared memory was purely a
consequence of the implementation; it was not a "feature" stuck in
for the benefit of any program, and if it disappears *nobody* has the
right to complain *at all*.

Unfortunately, some person who decides that warnings in the manual
page don't apply to them will use this feature anyway and complain
bitterly that somebody "broke" vfork if it is reimplemented so as not
to provide that sort of shared memory.  The warnings about "vfork"
have to be repeated simply in the hopes that some form of conditioned
reflex will be established amongst most programmers so that they
don't force implementors to provide this explicitly deprecated
side-effect of "vfork".

> Irregardless of what the man page says (you listen to man pages?  Use
> the force, read the source) the definitive use of vfork() is how it is
> used in csh.

Bullshit.  First of all, the line "Use the force, read the source" is
descriptive of a deficiency in UNIX, not of an advantage of UNIX.
One is forced to read the source in some cases because the UNIX
documentation is either 1) incorrect, 2) unclear, or 3) incomplete.
The UNIX documentation *should* be correct, clear, and complete; the
fact that it isn't merely means more work should be done on it.

Second of all, in this particular case the UNIX documentation *is*
correct, clear, and complete.  It tells you that these semantics of
"vfork" are a side-effect of the current implementation, not a
deliberate feature of the interface.  The fact that the source of a
*particular* UNIX implementation indicates that those semantics are
provided does not mean that those semantics are a characteristic of
the interface, and the fact that some piece of code knows that the
implementation works in this fashion does not mean that "vfork" is
intended to work in this fashion.  (The fact that some 4.1BSD code
used NULL as the name of a null character string most definitely does
not mean that NULL *is* the name of a null character string!  That is
an unfortunate characteristic of the VAX UNIX implementation; had it
not been, a lot of people at a number of computer companies might
have spent less time fixing other people's bugs.)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com