bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Win32] putenv modifications not inherited by child processed (Was:


From: John W. Eaton
Subject: Re: [Win32] putenv modifications not inherited by child processed (Was: Heap corruption in putenv)
Date: Sun, 17 Feb 2013 13:59:42 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11

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.

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.

jwe

Attachment: diffs.txt
Description: Text document

Attachment: test-putenv.c
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]