Date: Tue, 1 May 2007 12:10:11 -0400 From: John Baldwin <jhb@freebsd.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-src@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Andrey Chernov <ache@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c Message-ID: <200705011210.12839.jhb@freebsd.org> In-Reply-To: <20070501100642.GB823@turion.vk2pj.dyndns.org> References: <200704301516.l3UFGJbu019162@repoman.freebsd.org> <20070501000242.GA19510@nagual.pp.ru> <20070501100642.GB823@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 01 May 2007 06:06:42 am Peter Jeremy wrote: > On 2007-May-01 04:02:42 +0400, Andrey Chernov <ache@freebsd.org> 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. <rant> 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. </rant> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705011210.12839.jhb>