delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/06/14/13:54:31

From: cgf AT bbc DOT com (Chris Faylor)
Subject: [BUG] environment not inherited by fork
14 Jun 1997 13:54:31 -0700 :
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <EBs2nK.4Gu.cygnus.gnu-win32@bbc.com>
Reply-To: cgf AT bbc DOT com
X-Newsreader: trn 4.0-test57 (27 Apr 97)
Original-To: gnu-win32 AT cygnus DOT com
X-Mailer: Perl5 Mail::Internet v1.28
Original-Sender: owner-gnu-win32 AT cygnus DOT com

The following code illustrates a problem with cygwin.dll b18 (the Cygnus
release version).

#include <stdio.h>
main(int argc, char **argv)
{
putenv("FOO=BAR");
printf("parent FOO=%s\n", getenv("FOO"));
if (fork() > 0) {
    wait(0);
    exit(0);
}
printf("child FOO=%s\n", getenv("FOO"));
exit(0);
}

It erroneously produces the following output:

parent FOO=BAR
child FOO=(null)

This is due to the fact that there are two environ pointers being maintained:
one is in the "user space" the other is in "dll space".  The one in "dll space"
is the one that is updated by putenv() but fork overwrites this with the
"user space" one when it copies stuff.  I think that, if possible, the
routines in the .dll that manipulate the environment should only be using
the environ table in the user space.  Trying to keep the two pointers in
sync would otherwise be very difficult.

This unfortunately would require, I think, changes to the newlib code
to accomodate the gnuwin32 code.
-- 
http://www.bbc.com/	cgf AT bbc DOT com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019