On Jan 10 22:54, Eric Hoffman wrote:
> On Sun, 9 Jan 2005 13:19:53 +0100, Corinna Vinschen wrote:
> > Could you please prepare a short testcase, only containing the
> > necessary lines to reproduce the problem?
>
> I have attached 2 files to reproduce the problem. It is linked to the
> putenv() call and the env variable then being reset.
Thanks for the testcase.
> strcpy(fooflags,"fooflags=1");
> putenv(fooflags);
> *fooflags = '\0'; /* remove from environment after all */
Oh well. What happens is that your empty string results in a fatal
change in the Win32 environment propagated to the child application.
A Win32 environment consists of a long string of \0-terminated strings.
The end of the environment is indicated by a second \0, like this:
"a=b\0c=d\0e=f\0\0"
By setting one of the strings to \0 as you do, the propagated environment
contains an early \0:
"\0\0c=d\0e=f\0\0"
The result is that the propagated Win32 environment is actually empty.
Missing $PATH and $SYSTEMROOT are fatal and explain the socket problem
you encountered.
This is a bug in Cygwin insofar as Cygwin should not allow to propagate
empty strings to the child application. I'm preparing a patch right now.
In the meantime, don't do that. Replace
*fooflags = '\0';
by
unsetenv ("fooflags");
NB: The use of setenv/unsetenv is preferrable over using putenv anyway.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
