From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 16:39:10 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA37316A473; Thu, 5 Jul 2007 16:39:10 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 871D313C45A; Thu, 5 Jul 2007 16:39:09 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l65GeKAA034166; Thu, 5 Jul 2007 11:40:20 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 5 Jul 2007 11:38:53 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070705115816.GA50506@nagual.pp.ru> Message-ID: <20070705105922.F98700@thor.farley.org> References: <20070704143642.GA31254@nagual.pp.ru> <20070704150312.GB31683@nagual.pp.ru> <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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2007 16:39:11 -0000 On Thu, 5 Jul 2007, Andrey Chernov wrote: > On Wed, Jul 04, 2007 at 09:53:15PM -0500, Sean C. Farley wrote: >> The latest patch at the same URL fixes that issue. It basically >> deactivates all existing variables and inserts the new environ >> variables into the envVars array. > > Calling __clean_env(false) is good but the rest looks like a bit > overkill. It has the advantage that if environ was replace with an empty array or a list of variables that already were defined (limited copy of environment), then it would not need to make any allocations (i.e., usr.sbin/zic/zdump.c). Also, cleaning up almost everything and starting from the beginning would actually be trickier to get it right if using __build_env(). It would require adding more intelligence (complexity) to __build_env() to know how to add a new environ to an existing envVars array. Right now, it builds it from scratch. > 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. > Now verify_env() takes the role of build_env() too, moreover, may > cause setenv() to be called recursively which isn't good. Do you see a problem that I am missing, or are you suggesting a change to prevent potential problems from future changes? The test at issue is this: if (__merge_environ() == -1 || (envVars == NULL && __build_env() == -1)) 1. environ was changed 2. program calls setenv()[1] 3. setenv()[1] calls __merge_environ()[1] 4. __merge_environ()[1] calls setenv()[2] 5. setenv()[2] calls __merge_environ()[2] 6. __merge_environ()[2] returns 0 since environ == watchEnviron 7. setenv()[2] adds new name/value pair and returns 8. Jump to step 4 until environ is inserted. 9. __merge_environ()[1] returns 10. setenv()[1] returns 11. program is happy :) 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. Sean -- scf@FreeBSD.org