From: crvich AT raleigh DOT ibm DOT com
Subject: environ defined twice
29 Apr 1997 10:52:13 -0700
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <9704291336.AA28022.cygnus.gnu-win32@ode1.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: gnu-win32 AT cygnus DOT com
X-Mailer: ELM [version 2.4 PL22]
Original-Sender: owner-gnu-win32 AT cygnus DOT com


	Version: beta 17.1
	Platform: WinNT 4.00.1381

	Not sure if this has already been discussed (I searched the
archives, which only run through Dec 22, to no avail), but I've found
that environ is defined in both libc.a (environ.c) and libcygwin.a
(libccrt0.cc).  This causes confusing results, since the stdlib.h
functions (setenv, putenv, getenv) seem to be using "their" version,
while a browse through environ directly by my program uses the "other"
version.  Both versions are initially the same, but once you begin
modifying environ (with either the stdlib.h functions or directly
yourself), their uniqueness becomes apparent.

	My main concern is the way fork() and exec() behave (I'm
invariably invoking a shell, "cmd" for now), since they cause different
versions of environ to be visible to an invoked program...exec() by
itself causes the "other" version (the one that was altered manually)
to be seen by the invoked program, while fork() allows a subsequent
exec() to see the stdlib.h version.

	I assume an "extern" was forgotten in the libccrt0.cc 
declaration, correct?  Any simple fix in the meantime, aside from
changing libccrt0.cc myself and trying to update cygwin.dll?
-
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".