cvs commit: src/usr.sbin/sysinstall main.c

[Andrey Chernov]

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/