lkml.org 
[lkml]   [1999]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: vfork specs
Date
From
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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans