Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Jul 2007 17:09:00 +0400
From:      Andrey Chernov <ache@nagual.pp.ru>
To:        "Sean C. Farley" <scf@FreeBSD.org>
Cc:        freebsd-current <freebsd-current@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, Michal Mertl <mime@traveller.cz>
Subject:   Re: Environment handling broken in /bin/sh with changes to {get,set,put}env()
Message-ID:  <20070707130859.GA96605@nagual.pp.ru>
In-Reply-To: <20070705105922.F98700@thor.farley.org>
References:  <20070704101026.O77978@thor.farley.org> <20070704173905.T67251@fledge.watson.org> <20070704121316.A77978@thor.farley.org> <20070704180000.GA34042@nagual.pp.ru> <20070704144159.X77978@thor.farley.org> <20070704195939.GA35302@nagual.pp.ru> <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 05, 2007 at 11:38:53AM -0500, Sean C. Farley wrote:
>> Previously the goal of veryfy_env() is just deactivate, the goal of
>> build_env() is just build. It was build_env() who insetrts new environ
>> variables into envVars array in old variant, isn't?
> 
> Yes, it was.  Now, it is to merge in a new environ array.  I renamed it
> __merge_environ() to better reflect its new role.

Well, I see. You try to keep envVars[] between environ switch by that way. 

But it still look complicated and probably gains nothing. I.e. will be 
much _faster_ just free envVars[] (but not variables themselfs) and allow 
build_env() to calloc() new array for envVars and fills it from new 
environ. It is surely faster than calling setenv() for each variable just 
for sake of keepeng once allocated envVars[].

Moreover, environ switch commonly used to switch from large environ to 
smaller one (or to empty one), so the rest of old envVars[] array would 
keep unneccessary allocation.

> The alternative, which I had actually considered, is to split setenv()
> into __setenv() which is almost the entire current setenv() and a new
> setenv() that is just a wrapper around __setenv() with the beginning
> checks.  This seems a bit of a waste, but I may be mistaken.

Well, no recurse level increase problems but just slowdown.

-- 
http://ache.pp.ru/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070707130859.GA96605>