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

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

On Fri, Apr 21, 2006 at 03:45:54PM -0400, Pierre A. Humblet wrote:
>----- Original Message ----- 
>From: "Christopher Faylor" <xxx-xx-xxxxxxxx-xxxxx-xxxxxx@xxxxxx.xxx>
>To: <xxxxxx-xxxxxxx@xxxxxx.xxx>

>Sent: Friday, April 21, 2006 3:13 PM
>Subject: Re: [Patch] Make getenv() functional before the environment is 
>>On Fri, Apr 21, 2006 at 02:52:06PM -0400, Pierre A. Humblet wrote:
>>>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.
>But doesn't the program then have a pointer to memory that has been freed?
>That pointer can also be accessed after forks.

Isn't that always a possibility?  You can't rely on the persistence of
the stuff returned from getenv().


More information about the Cygwin-patches mailing list