Re: FreeBSD has setenv but not clearenv

[Colin Watson]

On Wed, Jun 05, 2013 at 06:59:24AM -0600, Eric Blake wrote:
> On 06/05/2013 06:36 AM, Colin Watson wrote:
> > Eric Blake wrote:
> >> clearenv() is non-standard (it is a glibc extension); but yes, glibc
> >> documents that "environ = NULL" is a portable alternative.
> > 
> > Hm, that's not in my libc.info.  Do you just mean the code?
> 
> I found it in 'man clearenv' on a Linux system; so maybe that's in the
> man-pages project instead of the glibc project.

Ah, right.

> >> And yes, it is probably quite easy to write a gnulib module that would
> >> provide clearenv everywhere, although I fail to see why applications
> >> need the overhead of a function call when an assignment would do.
> > 
> > I was wary about other C libraries that might assume that the environ
> > pointer can always be dereferenced; and e.g.
> > http://hg.dovecot.org/dovecot-2.0/file/74d9f61e224d/src/lib/env-util.c#l56
> > has some specific portability notes which indicate that "environ = NULL"
> > isn't an adequate replacement everywhere.  This is the kind of reason I
> > like to use Gnulib so that it can shield me from this nonsense,
> > especially if somebody discovers another OS with some newer crazy
> > requirement. :-)
> 
> POSIX requires assignment to 'environ' to work when doing wholesale
> replacement of an environment,

Which is fine except for the assertion in the link above that doing that
crashes on OS X, POSIX or no POSIX ... but allocating an empty
environment with calloc intuitively seems reasonably sensible, I'll
grant.

> with one caveat - if your environment requires certain variables to
> exist to guarantee conformance (think POSIXLY_CORRECT or PATH, for
> example), then wholesale nuking of the environment may result in your
> program transitioning into a non-conforming setup, where things may
> misbehave compared to your expectations since you are no longer
> protected by POSIX guarantees.  Thus, while 'environ = NULL' and
> 'clearenv()' do the same thing, neither of them is very wise compared
> to constructing an environment that preserves the essentials rather
> than stripping everything.

Admittedly this is true.  In my case it's too late - I've already
exposed a piece of API in libpipeline that promises to do clearenv, so
unwise or not I can't go back on that now (or, rather, I don't want to
get into the business of deprecation cycles).  I've added a warning to
my documentation.

It sounds like the best answer, then, is for me to work around this in
my package, so I'll do that.  Thanks.

-- 
Colin Watson                                       address@hidden