Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucla-cs!twinsun!eggert
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.sys.sgi
Subject: Re: bug in vfork semantics under IRIX 3.3.1
Message-ID: <1990Dec3.024237.23749@twinsun.com>
Date: 3 Dec 90 02:42:37 GMT
References: <1990Nov29.035827.1302@alias.uucp> <1990Nov30.041307.15489@twinsun.com> <1990Dec2.195600.25725@odin.corp.sgi.com>
Sender: news@twinsun.com
Organization: Twin Sun, Inc
Lines: 20
Nntp-Posting-Host: ata

jmb@patton.wpd.sgi.com (Doctor Software) writes:

	Thus, the easiest way to implement vfork() is ...
		# define vfork	fork

Several programs (e.g. perl, rn) have autoconfiguration scripts that determine
whether the host has a vfork(), and use fork() otherwise.
This strategy fails under IRIX 3.3, which has a vfork() that doesn't work.
A programmer who knows about the IRIX vfork bug can work around this by hand,
but it's unrealistic to expect this of every perl and rn maintainer.
If SGI wants to make it easy to port software to their machines,
IRIX should have either a working vfork(), or no vfork() at all.


	The entire computer industry would grind to a halt if every company
	tried to make sure it only shipped "documented" entry points to it's
	libraries.

If IRIX's vfork() is indeed just an undocumented library entry point that has
nothing to do with BSD's vfork(), then it should be given a different name.