This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: vfork specs
- To: Stanislav Meduna <stano@trillian.eunet.sk>
- Subject: Re: vfork specs
- From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
- Date: Sat, 16 Jan 1999 09:19:39 -0500
- cc: drepper@cygnus.com, libc-alpha@cygnus.com, linux-gcc@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
In message <199901160921.KAA04233@trillian.eunet.sk>, Stanislav Meduna
writes:
+-----
| > Assume this:
| >
| > pid_t
| > baz ()
| > {
| > return vfork ();
| > }
|
| The Single Unix Specification says:
|
| : The vfork() function has the same effect as fork(),
| : except that the behaviour is undefined if the process
| : created by vfork() either modifies any data other than
| : a variable of type pid_t used to store the return value
| : from vfork(), or returns from the function in which
| : vfork() was called, or calls any other function before
| : successfully calling _exit() or one of the exec family
| : of functions.
|
| So this one is (if I interpret it correctly)
| definitly bad code.
+--->8
Yes. Return in the child -> the parent's stack pointer is now left pointing
to unknown data, because the stack is shared but the stack pointers
(obviously) aren't. (Unless #define vfork fork.)
vfork() is a horrible kludge. This is why.
--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.