tripped some excess/outdated text from the BUGS section.

diff --git a/man2/vfork.2 b/man2/vfork.2
index 7e72a9c0edcf57c7679b53af4a46798a584dc287..dc045351c989cefd5ffa891fd66d6c9ea9bf9883 100644 (file)
--- a/man2/vfork.2
+++ b/man2/vfork.2
@@ -119,13 +119,6 @@ as it will, in that case, be made synonymous to
 .BR fork ().\c
 "
 
-Formally speaking, the standard description given above does not allow
-one to use
-.BR vfork ()
-since a following
-.BR exec ()
-might fail, and then what happens is undefined.
-
 Details of the signal handling are obscure and differ between systems.
 The BSD manpage states:
 "To avoid a possible deadlock situation, processes that are children
@@ -134,12 +127,13 @@ in the middle of a
 are never sent SIGTTOU or SIGTTIN signals; rather, output or
 .IR ioctl s
 are allowed and input attempts result in an end-of-file indication."
-
-Currently (Linux 2.3.25),
-.BR strace (1)
-cannot follow
-.BR vfork ()
-and requires a kernel patch.
+.\"
+.\" As far as I can tell, the following is not true in 2.6.19:
+.\" Currently (Linux 2.3.25),
+.\" .BR strace (1)
+.\" cannot follow
+.\" .BR vfork ()
+.\" and requires a kernel patch.
 .SH HISTORY
 The
 .BR vfork ()
@@ -157,7 +151,8 @@ other architectures) it is an independent system call. Support was
 added in glibc 2.0.112.
 .SH "CONFORMING TO"
 4.3BSD, POSIX.1-2001.
-
+.\" FIXME Mar 07: in the draft of the next POSIX revision, the spec for 
+.\" vfork() has been removed.
 The requirements put on
 .BR vfork ()
 by the standards are weaker than those put on