From owner-cvs-all@FreeBSD.ORG Tue May 1 19:31:48 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D8CE16A406; Tue, 1 May 2007 19:31:48 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF9F13C448; Tue, 1 May 2007 19:31:47 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l41JVkBh011480; Tue, 1 May 2007 23:31:46 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l41JVkMr011479; Tue, 1 May 2007 23:31:46 +0400 (MSD) (envelope-from ache) Date: Tue, 1 May 2007 23:31:46 +0400 From: Andrey Chernov To: John Baldwin Message-ID: <20070501193146.GD10323@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , John Baldwin , Peter Jeremy , Alfred Perlstein , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org References: <200704301516.l3UFGJbu019162@repoman.freebsd.org> <20070501000242.GA19510@nagual.pp.ru> <20070501100642.GB823@turion.vk2pj.dyndns.org> <200705011210.12839.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705011210.12839.jhb@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Alfred Perlstein , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2007 19:31:48 -0000 On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote: > Now, that said, apparently some folks on this list CAN'T READ. > > Linux has the new putenv() algorithm already, so if any software breaks with > this, it is _ALREADY_ broken on Linux. Please consider that before ripping > ache@ a new one here. As much as BSD wants to feel really important, in > truth, most of the software in ports probably runs more often on Linux than > on BSD, so I think the chances of non-trivial real-world breakage are fairly > small. And I already tell exactly so about Linux and ports already portable in the threads. Perhaps they will hear you better, but the changes in question are already backed out and I can't work on them under such pressure. In case anyone brave will be found, feel free to restore, and then I'll promise my help dealing with all bugs they may cause. > So with all that said, it seems we have four groups of usage with respect to > putenv(3): > > - give it a stack allocated or otherwise non-persistent buffer (note that > string constants are persistent, even if they are read-only) as the first > argument. This violates POSIX I guess, and would break on at least Linux and > Solaris (judging by Open Solaris's putenv() implementation). Agreed. > - pass in a persistent buffer (constant, allocated memory, etc.) and change > the contents later expecting that changing the buffer won't change the > environment. This breaks Linux and Solaris and POSIX as well. Agreed. > - pass in a persistent buffer and don't change it afterwards (at least not > until after a later call to putenv or setenv for the same variable). This > works for both impls and is probably the vast majority of usage. Agreed. Most programs don't use the modify-env-on-the-fly feature, but it is at the current moment, just because several putenv() implementations was hanging around when no one standartized. When POSIX explicitly standartize modify-env-on-the-fly feature, more programs will tend to try it at time. > - pass in a persistent buffer and change the contents expecting that it will > change the value returned from getenv(). This doesn't work on BSD, but does > on Linux + Solaris + POSIX + FreeBSD 7. Agreed (but not for FreeBSD7 now). > So we have four groups: 1, 2, 3 (likely the vast majority), and 4. (4) is > fixed by this commit, and works on Linux, Solaris, and POSIX. (1 + 2) are > broken by this commit, but they also don't work on Linux, Solaris, or POSIX. > So the question seems to be, which set is larger, programs that depend on (1 + > 2), or programs that depend on (4)? Also, which set is going to get larger > as time moves on given Linux's implementation? If you assume (as I do), that > most programs fall into (3) anyway, then it really isn't all that important > anyway. Set 3 is larger now, but popularity of set 4 perhaps will be increased in the future because it is standard. Set 1 is small and will be decreased. -- http://ache.pp.ru/