Date: Tue, 01 May 2007 16:39:41 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: ache@FreeBSD.ORG Cc: alfred@FreeBSD.ORG, jhb@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c Message-ID: <20070501.163941.-2001109237.imp@bsdimp.com> In-Reply-To: <20070501193146.GD10323@nagual.pp.ru> References: <20070501100642.GB823@turion.vk2pj.dyndns.org> <200705011210.12839.jhb@freebsd.org> <20070501193146.GD10323@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey,
Thanks for taking the time to track down all the problems that the
initial commit caused. Thank you also for showing the maturity to
gracefully back out the changes until they can be discussed in more
depth. I know that there's been a lot of emotion expressed over these
changes, and I complement you on keeping your cool during the
discussions.
I'd like to suggest that people interested in this continue the
discussion in arch@ which is a more appropriate... This post seems to
be the most relevant of the ones from src-commits.
Warner
In message: <20070501193146.GD10323@nagual.pp.ru>
Andrey Chernov <ache@freebsd.org> writes:
: 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/
:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070501.163941.-2001109237.imp>