This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: vfork specs


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]