Fix for memory leak in setenv/unsetenv
Sean C. Farley
sean-freebsd at farley.org
Tue Nov 7 14:38:52 UTC 2006
On Thu, 19 Oct 2006, Sean C. Farley wrote:
> On Thu, 19 Oct 2006, Stefan Esser wrote:
>> I've got to admit, that I have not looked your patch, but the only
>> drawback seems to be that the last instance of a variable in the
>> environment space has to be located in getenv() (maximizing the
>> search time ...).
>
> Actually, the first active variable found is returned by getenv() even
> if another would be found later. This does make me think that if
> changed the way the environment variable array was built to only
> contain the first instance of each variable instead of all instances
> then a search by getenv() from the end of the array backwards would be
> faster. A cheap alternative is to create the array in reverse.
>
>> Always using the last allocated (largest) slot for storage of new
>> values of environment variables would result in nearly reasonable
>> behavior. A cached pointer does either point to the value of the
>> variable at the time of the getenv(), or to the last value assigned
>> to the environment variable that does not exceed the allocated size.
>
> I will look at changing it.
I changed it to create the array in reverse and to search it from the
end.
I played with crt1.c to have it initialize the new environment and clean
it up via atexit(). The feeling I get is that this may be disliked
since malloc_init() is not called here. Would there be a reason not to
have things such as memory allocation and an environment (such as I have
been doing) initialized and/or cleaned up here?
Would there be anything else I should code to have this be a viable
replacement to the current implementation of the setenv-family of
functions?
Sean
--
sean-freebsd at farley.org
More information about the freebsd-current
mailing list