IIUG Software Repository Files

From: johnl@informix.com (Jonathan Leffler)
Date: 3 Jan 1996 19:13:04 -0500

Hi,

The problem is almost certainly in the requirements of putenv(), which
takes the pointer you provide and stashes a reference to that string in the
environment area.  If your pointer was to a functions local variable, then
the environment stored by putenv() changes everytime the space the local
variable occupied is re-used by some new function -- a probable cause of
your problems.  Even if you overcome this problem by providing malloc'd
space, if you ever reset an environment variable, then you leak the
previous malloc'd value, as putenv() doesn't release the space for you --
it can't, because it doesn't know you malloc'd it!

I attach some code which provides a leak-proof version of putenv() called
setenv().  By default, it compiled with -DRADICAL_SETENV in effect, which
means that it also provides versions of getenv(), putenv() and unsetenv().
It can also be compiled with the option -DCONSERVATIVE_SETENV, in which
case setenv() uses the system-provided putenv() to handle the actual
environment modification, but it allocates memory to copy the value
provided by the caller and keeps a record of what has been allocated, and
frees it when the value is changed.  You do not get unsetenv() in this mode
because there is no reliable way to provide it.  Note that if your code
currently handles putenv() correctly (ie, it ensures that the space it
gives to putenv() is not reused, then this implementation of putenv() gives
you a leak because it automatically makes a copy of what is passed into
putenv() and does not try to free it.  That is why setenv() is the
preferred interface -- it has different semantics from putenv().  You may
want to compile the code with -DNDEBUG to disable extensive assertion
checking -- but reenable the assertions if you find yourself making
modifications as they catch a lot of problems very quickly.  Note that this
code keeps the environment in sorted order, and uses ANSI C prototypes.
Compiling with -DTEST can create a self-contained executable which tests
the package.  Adding -DPROFILING suppresses some printing that completely
wrecks timing comparisons (eg Quantify by Pure Software) run on the code.
The code has been tested with Purify, Quantify and PureCoverage and is
reasonably well behaved with all of these -- it is memory clean with
Purify.

This code is also included in the Informix WWW software (CGI compliant)
available via http://www.informix.com (choose the Freeware option).

Yours,
Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>