svn commit: r199983 - in head: lib/libc/stdlib tools/regression/environ

[Brian Fundakowski Feldman]

On Tue, Dec 01, 2009 at 01:06:03PM +0300, Andrey Chernov wrote:
> On Tue, Dec 01, 2009 at 05:04:31AM +0000, Brian Feldman wrote:
> > -	if (environ == NULL || environ[0] == NULL)
> > -		return (NULL);
> > -	else if (envVars == NULL || environ != intEnviron)
> > +	if (envVars == NULL)
> >  		return (__findenv_environ(name, nameLen));
> > -	else {
> > -		envNdx = envVarsTotal - 1;
> > -		return (__findenv(name, nameLen, &envNdx, true));
> > -	}
> > +
> > +	/* Synchronize environment. */
> > +	if (__merge_environ() == -1)
> > +		return (NULL);
> > +
> > +	envNdx = envVarsTotal - 1;
> > +	return (__findenv(name, nameLen, &envNdx, true));
> >  }
> 
> __merge_environ() should be avoided here for speed reasons.

If the corrupt environment warnings are not actually that useful, then 
I agree that there's no other reason not to defer __merge_environ().

I actually wanted to have getenv(3) produce the warnings even if one of
the other (modification) functions was never called, but that seemed
impossible to do correctly without also having it call __build_environ().

The warnings I don't care much about, but having getenv(3) treat the
environment as sane when setenv(3)/unsetenv(3)/putenv(3) operations
are indefinitely failing is wrong.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\