putenv stops working after assigning to environ.

putenv stops working after assigning to environ.

[Kaz Kylheku]

Hi,

I have found that if we do this:

   extern char **environ;
   static char *empty_env[1] = { 0 };
   environ = empty_env;

then the environment becomes empty as far as executing child programs;
e.g. if we fork and exec the "env" utility, it shows an empty
environment.

However, after the above assignment statement, the putenv
function no longer works. It returns 0, indicating success,
but the environment stays empty, and the newly installed
variable cannot be retrieved with getenv.

POSIX suggests that there are implementations whose putenv
and setenv functions notice that the environment has been
changed by environ manipulation, reallocate the array (and
keep working).

I don't see anything in POSIX which says that they are permitted
to stop working.

"Applications can change the entire environment in a single
operation by assigning the environ variable to point to an array
of character pointers to the new environment strings.
After assigning a new value to environ, applications should
not rely on the new environment strings remaining part of the
environment, as a call to getenv(), putenv(), setenv(), unsetenv(),
or any function that is dependent on an environment variable may,
on noticing that environ has changed, copy the environment
strings to a new array and assign environ to point to it."

No reasonable interpretation of this says that these functions
may not notice that environ has changed, only that they may
copy it if it has changed (the most obvious reason for which
would be that it has no space for a new variable).

Re: putenv stops working after assigning to environ.

[Kaz Kylheku]

On 2021-09-25 11:28, Kaz Kylheku wrote:
> Hi,
> 
> I have found that if we do this:
> 
>   extern char **environ;
>   static char *empty_env[1] = { 0 };
>   environ = empty_env;

Please disregard this report; it works fine.

The problem was misuse of the putenv function.

The caller of putenv agrees to pass ownership of the string
to the environment management code, and that contract
was not being observed in my test code; the code was freeing
the strings passed to putenv.

There is no way to make it work with putenv in my situation,
so I switched the code to setenv and all is well.

The ways of using putenv without causing a memory leak
are extremely limited.