Using environment variables without leaking memory?

[Rich Felker]

On Tue, Oct 31, 2006 at 04:46:51PM -0500, Rob Landley wrote:
> On Tuesday 31 October 2006 4:12 pm, Erik Andersen wrote:
> > On Tue Oct 31, 2006 at 01:09:26PM -0500, Rob Landley wrote:
> > > I wonder if Erik's been following this conversation...
> > 
> > of course
> 
> So would you prefer a patch to uClibc that makes unsetenv() free environment 
> variables created by setenv() (but not those added by putenv), or would you 
> prefer a patch that leaves the current unsetenv() behavior alone and adds a 
> new freeenv() which frees variables added by either setenv() or putenv() (but 
> not those inherited from exec)?

putenv variables are equivalent to exec-inherited ones with regard to
where you must regard them to live. It's the caller's responsibility
to free them, if they were allocated. I think you said this in another
email already but I'm just clarifying.

> The first is allowed by SUSv3 (possibly even suggested by it) but could easily 
> break existing programs.  The second ignores the standard entirely but 
> definitely wouldn't break any existing programs.
> 
> Right now, environment variables just leak, and there's no obvious way to use 
> the library functions and _not_ to leak them.

I would prefer the former because, while it could break broken
applications, it also eliminates the existing memory leak in existing
correct applications. My implementation already does this, except that
it's not as smart as yours with regards to how it distinguishes
setenv/putenv/original vars. Someday I'll update mine to use your
better design.

BTW it should already be possible to avoid memleaks if you just use
putenv and not setenv, but maybe glibc/uclibc strdup putenv entries or
something..? :(

Rich