From owner-cvs-src@FreeBSD.ORG Tue May 1 18:19:34 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B780916A400; Tue, 1 May 2007 18:19:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id DF68E13C484; Tue, 1 May 2007 18:19:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l41IJV34024391; Tue, 1 May 2007 14:19:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Peter Jeremy Date: Tue, 1 May 2007 12:10:11 -0400 User-Agent: KMail/1.9.6 References: <200704301516.l3UFGJbu019162@repoman.freebsd.org> <20070501000242.GA19510@nagual.pp.ru> <20070501100642.GB823@turion.vk2pj.dyndns.org> In-Reply-To: <20070501100642.GB823@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200705011210.12839.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 01 May 2007 14:19:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3189/Tue May 1 12:02:13 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, Alfred Perlstein , Andrey Chernov , src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2007 18:19:34 -0000 On Tuesday 01 May 2007 06:06:42 am Peter Jeremy wrote: > On 2007-May-01 04:02:42 +0400, Andrey Chernov wrote: > >On Mon, Apr 30, 2007 at 06:57:17PM -0400, David Schultz wrote: > >> I think Alfred is absolutely right, and this is a pretty major > >> POLA violation. > > > >That's -current for. Do you suggest to wait yet more N years to commit > >exact that stuff? > > I would have expected this proposed change to get a heads-up in > current@ first. _Especially_ since there is a current thread in > current@ about fixing some long-standing memory leaks in our *env() > functions. Implementing a major POLA violation without any warning > whilst other changes to the same code are being discussed in one of > the mailing lists could be seen as impolite. I already talked with ache@ about that, and his changes are completely orthogonal to the setenv(3) fixes. 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. 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). - 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. - 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. - 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. 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. -- John Baldwin