From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 00:08:56 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 44C2516A401 for ; Sat, 14 Jul 2007 00:08:56 +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 E037213C467 for ; Sat, 14 Jul 2007 00:08:55 +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 l6E0AjoT057298; Fri, 13 Jul 2007 19:10:45 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 19:08:37 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070713224608.GB21695@nagual.pp.ru> Message-ID: <20070713184543.A26096@thor.farley.org> References: <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> <20070713142545.K26096@thor.farley.org> <20070713202433.GA19856@nagual.pp.ru> <20070713203915.GA20270@nagual.pp.ru> <20070713171942.Q26096@thor.farley.org> <20070713224608.GB21695@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,AWL,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 Subject: Re: Environment handling broken in /bin/sh with changes to t,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: Sat, 14 Jul 2007 00:08:56 -0000 On Sat, 14 Jul 2007, Andrey Chernov wrote: > On Fri, Jul 13, 2007 at 05:27:58PM -0500, Sean C. Farley wrote: >> Does that mean that environ is untouched or that the environment is >> unchanged? They seem to use both words (environ and environment) in >> the documentation making me think they are not necessarily the same >> thing. Currently, non-getenv() calls rebuilds the environ array if >> having never been changed before, but the "environment" is >> "unchanged" if the variable does not exist. Should that not meet >> that requirement? > > IMHO by the environment they means environ contents, not pointers, > because they say: > > "The setenv() function shall update the list of pointers to which > environ points." I want to make certain what you mean. Upon the first call to setenv() or unsetenv(), the environ is rebuilt. The contents are the same. Before and after execution if no data was changed, environ will look like this. The addresses to environ and to each pointer will be different. Are you saying that the addresses should not change for environ, environ[0-1] or all? environ[0] = "PATH=/bin" environ[1] = "USER=root" environ[2] = NULL I found this in the "Rationale" for getenv(): Conforming applications are required not to modify environ directly, but to use only the functions described here to manipulate the process environment as an abstract object. Thus, the implementation of the environment access functions has complete control over the data structure used to represent the environment (subject to the requirement that environ be maintained as a list of strings with embedded equal signs for applications that wish to scan the environment). This constraint allows the implementation to properly manage the memory it allocates, either by using allocated storage for all variables (copying them on the first invocation of setenv() or unsetenv()), or keeping track of which strings are currently in allocated space and which are not, via a separate table or some other means. This enables the implementation to free any allocated space used by strings (and perhaps the pointers to them) stored in environ when unsetenv() is called. A C runtime start-up procedure (that which invokes main() and perhaps initializes environ) can also initialize a flag indicating that none of the environment has yet been copied to allocated storage, or that the separate table has not yet been initialized. In fact, for higher performance of getenv(), the implementation could also maintain a separate copy of the environment in a data structure that could be searched much more quickly (such as an indexed hash table, or a binary tree), and update both it and the linear list at environ when setenv() or unsetenv() is invoked. It does not distinguish between whether or not any data changed when changing environ. It just says "first invocation of setenv() or unsetenv()". Sean -- scf@FreeBSD.org