On Fri, Apr 21, 2006 at 02:52:06PM -0400, Pierre A. Humblet wrote: >----- Original Message ----- >From: "Corinna Vinschen" >To: <[email protected]> >Sent: Friday, April 21, 2006 1:23 PM >Subject: Re: [Patch] Make getenv() functional before the environment is >initialized > > >>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. >> > >Corinna, > >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. cgf
