Re: env -u behavior

[Jim Meyering]

Eric Blake wrote:

> Eric Blake <ebb9 <at> byu.net> writes:
>
>> Glad you agree.  How about this patch?
>>
>> * src/env.c (main): Use unsetenv rather than putenv to remove
>> items from environ, and check for failure.
>
> Since there is a gnulib module for unsetenv, I've modified my proposed patch 
> to
> pick it up.  Meanwhile, I noticed that we can kill some dead code.  (For that
> matter, stdbuf wasn't even modifying environ directly.)
>
> By the way, the POSIX folks recently admitted that setenv() is better than
> putenv(), in that the former allows implementations to provide O(log n)
> searching (by maintaining env as a sorted array) or even O(1) searching (by
> maintaining a hidden counterpart hashtable) compared to the traditional O(n)
> behavior (of stepping through every array entry), if the implementation is
> allowed to assume that the user can't muck inappropriately with pointers
> reachable from raw environ.  But in the current wording of their ruling, they
> also stated that changing raw environ (as currently done in env.c and su.c)
> renders an application non-conforming, with behavior of subsequent functions
> (like execve) no longer being guaranteed.  In other words, when it is time to
> replace the environment, it is unportable to use the O(1) swap of setting
> environ=new_environ, and a compliant app must instead implement an O(n) 
> clearenv
> () wrapper (for systems where it is not already provided natively) which
> repeatedly calls unsetenv() for every name currently in the environment.
> http://austingroupbugs.net/view.php?id=167
> http://www.opengroup.org/austin/mailarchives/ag/msg44144.html

Interesting.  Thanks for the summary.

> The Austin group also recently opened up their bug database for anonymous
> viewing, so the above link should no longer require you to register.
> https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=12951

Good news.

> Personally, I'm not too worried about the Austin ruling - yes, our code in
> env.c and su.c is no longer strictly conforming, but until someone points out
> an actual system where directly resetting environ messes up their expected
> behavior, I'm not going to try to patch the code based on paranoia.  And I 
> will
> be chiming in to the Austin group asking that swapping environ itself (which 
> is
> different than altering contents reachable from environ) be supported by the
> standards, similar to Joerg Schilling's request:
> http://www.opengroup.org/austin/mailarchives/ag/msg43077.html
>
> At any rate, is this patch OK to apply?

Yes.  That looks fine.
Thanks!