> You need to hold __environ_lock across this call.

That is what I get for doing this after a long day.  I knew
that I just missed 'em.  Thanks.

> 
> > Index: setenv.c
> > ===================================================================
> > RCS file: /cvsroot/src/lib/libc/stdlib/setenv.c,v
> > retrieving revision 1.21
> > diff -u -r1.21 setenv.c
> <snip>
> > +	environ = p;
> > +	environ[cnt + 1] = NULL;
> 
> These two would be safer the other way around (just in case someone
> is reading environ without the lock held.

Doesn't just switching the order solve one problem and create
another?  Actually, wouldn't it need to be more like this?

p[cnt + 1] = NULL;
environ = p;

> 
> AT line 95 the code has:
> 
> 	if (strlen(c) >= l_value) {     /* old larger; copy over */
> 		while ((*c++ = *value++) != '\0');
> 		rwlock_unlock(&__environ_lock);
> 		return (0);
> 	} 
> 
> This isn't safe anymore....

Isn't it?  I guess I'm missing something then as I don't see it.
Probably not wise to be setenv()ing a variable previously putenv()ed
but it doesn't appear any more unsafe than it was...

> I'm also not 100% about how the code behaves in the presence of
> environment string that don't contain an '=' (eg after putenv("fred");).
> 
> It needs to do something sensible.

It should probably return -1 like the current putenv() function.
I don't see anything in the standard that prevents this.  I'll
check what other implementations do.

> 	David

-- 
Brian Ginsbach                          Cray Inc.
email: ginsbach@cray.com                I/O Software Group
voice: (651) 605-8968                   1340  Mendota Heights Road
  fax: (651) 605-9001                   Mendota Heights, MN 55120