On Thu, Nov 24, 2011 at 05:15:30PM +0800, Mark wrote: > If you free the string, it will cause the environment variable unavailable. > More details please see the following text extracted from manual of > "putenv": > > The libc4 and libc5 and glibc 2.1.2 versions conform to SUSv2: > the pointer string given to putenv() is used. In particular, this > string becomes part of the environment; changing it later will > change the environment. (Thus, it is an error is to call putenv() with > an automatic variable as the argument, then return from the calling > function while string is still part of the environment.) However, > glibc 2.0-2.1.1 differs: a copy of the string is used. On the one > hand this causes a memory leak, and on the other hand it violates > SUSv2. This has been fixed in glibc 2.1.2.
I don't think this matters since os-win32.c is only built for mingw, which uses the Microsoft C runtime and not glibc. However, there is no documentation for putenv(3) on MSDN because the function has been deprecated :(. So I think the safest thing to do is to assume this will leak memory but we are not allowed to free the string. Either you could investigate the new _putenv(3) and test the Windows build to make sure it works. Or you could send a patch that adds a comment explaining why there is a memory leak here. Stefan
