delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/04/29/10:52:13

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
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".

- Raw text -


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