Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: Date: Wed, 12 Jan 2005 22:28:44 +0100 From: Eric Hoffman Reply-To: Eric Hoffman To: cygwin AT cygwin DOT com Subject: Re: execv and then socket: "operation not permitted" In-Reply-To: <20050111122015.GP23702@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050109121953 DOT GA5017 AT cygbert DOT vinschen DOT de> <20050111122015 DOT GP23702 AT cygbert DOT vinschen DOT de> X-IsSubscribed: yes Thanks for the help! That's about the only significant change in about 37000 lines of C code of a legacy application dating back to 1998... quite a testimony to both the original programmer (not me!) skills and Cygwin conformance to standards. Cheers, Eric On Tue, 11 Jan 2005 13:20:15 +0100, Corinna Vinschen wrote: > 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 AT cygwin DOT 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/ > > -- 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/