Re: [Win32] putenv modifications not inherited by child processed (Was: Heap corruption in putenv)

[Michael Goffioul]

On Sun, Feb 17, 2013 at 1:59 PM, John W. Eaton <address@hidden> wrote:

On 02/15/2013 03:16 PM, Michael Goffioul wrote:

On Fri, Feb 15, 2013 at 2:10 PM, Paul Eggert <address@hidden

<mailto:address@hidden>> wrote:

    On 02/15/2013 07:10 AM, Michael Goffioul wrote:
     > I guess the only solution to this problem is to always _putenv
    and not manipulate "environ" directly.

    Thanks, is that something you can write and contribute
    to the GNU project?  This sort of thing really requires
    Microsoft expertise, which I don't have.


I can give it a try, but not before a couple of days. Also to avoid
breaking things, what is the putenv module supposed to solve? From what
I understand, it is:
- make putenv("VARNAME") remove VARNAME from the environment
- make putenv("VARNAME=") create and empty environment variable
Is there anything else?

Reading the specs here [1], I don't think the bit: "In either case, the

string pointed to by /string/ shall become part of the environment, so

altering the string shall change the environment." is actually possible.
I believe _putenv ultimately calls SetEnvironmentVariable [2] and
nothing there says that altering the given string will effectively alter
the environment.

Michael.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/putenv.html
[2]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686206(v=vs.85).aspx

How about something like the attached patch?  The program I used for testing (modified from Michael's, and with the modified putenv function included) is also attached.

I'm not sure I like the way I've nested the conditionals, or if it is even the right thing to do.  Maybe it would be better to leave the original code as it was and just have a separate version for Windows systems that uses _putenv and SetEnvironmentVariable.  I'm willing to rework this as necessary.

THe situation is a bit messy, because of the manipulation of the environment at 2 different levels (C runtime and Win32). You have _putenv, environ and SetEnvironmentVariable. _putenv will update environ and call SetEnvironmentVariable. Manipulating environ has no effect at Win32 level. And I believe SetEnvironmentVariable will not update environ.

When putting everything together, I think the best trade-off is to use always _putenv, and covering the cases of putenv("VAR") and putenv("VAR=") (if possible). 

 

In any case, I think it is important to fix putenv so that we not have to do some tricks at the time of subprocess creation in order for the environment to be passed to subprocesses.  Relying on that is likely to lead to unexpected results and problems that are hard to debug.  I think it is unreasonable to expect that we can control the way all subprocesses are created.

Agreed. 

Michael.