[Patch] Make getenv() functional before the environment is initialized

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Fri Apr 21 19:13:00 GMT 2006

On Fri, Apr 21, 2006 at 02:52:06PM -0400, Pierre A. Humblet wrote:
>----- Original Message ----- 
>From: "Corinna Vinschen"
>To: <cygwin-patches@cygwin.com>
>Sent: Friday, April 21, 2006 1:23 PM
>Subject: Re: [Patch] Make getenv() functional before the environment is 
>>On Apr  6 12:35, Pierre A. Humblet wrote:
>>>       * environ.cc (getearly): New function.
>>>          (getenv) : Call getearly if needed.
>>Thanks for the patch and sorry for the loooong delay.  I've applied a
>>slightly tweaked version of your patch, which uses a function pointer in
>>getenv, instead of adding a conditional.
>Thanks! Since sending the patch, I have found some issues with it :(
>In particular GetEnvironmentStrings returns a big block of
>storage that should be free (which we can't do), and that is
>going to be lost on a fork, potentially leading to trouble.
>Thus I have another implementation using GetEnvironmentValue
>and cmalloc. (with HEAP_1_MAX, so that it will be released
>on the next exec).
>I also take advantage of spawn_info, whose existence I had forgotten.
>Overall it's also simpler.
>Here is another patch, sorry for not sending this earlier.

I don't see any reason to permanently allocate memory with cmalloc.

I think that using GetEnvironmentStrings is still the right choice here.
You just have to make sure that it gets freed.  I'm going to check in a
cleanup of getearly which will move the rawenv variable to a static
which will potentially be used by environ_init.  Then environ_init will
free it if it has been previously set.

I've made some other minor stylistic changes to the function as well.


More information about the Cygwin-patches mailing list