From: Daniel K. O. <dan...@gm...> - 2007-02-23 19:11:17
|
Tor Lillqvist escreveu: > Daniel K. O. writes: > > that's necessary for putenv() - it doesn't copy the argument, it > > just points to it > > It does? > Well, I was just pointing the remark on the GNU libc documentation, that claims "This function is part of the extended Unix interface", so I assume it's the most widely expected behavior. Of course, you can easily implement one that works differently from the rest of the world - and looks Microsoft likes this approach. Good thing environment variables are mostly useless on Win32. > Looking at the sources for Microsoft'c putenv() also verifies that > putenv() indeed *does* copy its argument to dynamically allocated > memory. > Thanks for the information. Now, looking at autoconf documentation, there's a bit on this: `putenv' POSIX specifies that `putenv' puts the given string directly in `environ', but some systems make a copy of it instead (eg. glibc 2.0, or BSD). And when a copy is made, `unsetenv' might not free it, causing a memory leak (eg. FreeBSD 4). POSIX specifies that `putenv("FOO")' removes `FOO' from the environment, but on some systems (eg. FreeBSD 4) this is not the case and instead `unsetenv' must be used. On MINGW, a call `putenv("FOO=")' removes `FOO' from the environment, rather than inserting it with an empty value. No mention about the copying vs. just pointing on MinGW. Now this seems a really tricky function. In practice, it shouldn't do any harm to leak a few small strings just once across all the program execution. But it's really troubling that there's no way to guarantee the semantics even across different unix implementations. -- Daniel K. O. |