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

[John Baldwin]

On Tuesday 01 May 2007 06:06:42 am Peter Jeremy wrote:
> On 2007-May-01 04:02:42 +0400, Andrey Chernov <ache at 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