wputenv() cross tool-chain usage

[adamyg]

Heap analysts detected occasional runtime corruption in additional to exit crashes, pointing at environment variable management; results are varyed dependent on the tool-chain, msvc, owc and mingw32/64. Review and resolve _[w]putenv() usage, certain semantics are assumed but not guaranteed, for example _wputenv() memory semantics

Issues:

• _[w]getenv API's are non-standard, win32 specific, compared to the traditional POSIX putenv; putenv has an explicit usage warning, the ... string becomes part of the environment, so altering the string changes the environment.stated the variable is referenced, glibc 2.1.2+ explicity states the storage is referenced, not copied.

• Unlike putenv, _wputenv memory semantics are assumed to copy implying only local scope is required. Reviewing an older msvc runtime (vc98), _wputenv() copied the value, representing one the first published implementations; the semantics have not changed since, Unfortunately semantics are not explicitly stated within public definitions yet could be implied from the function prototype plus putenv usage warnings are not present.

• 3rd party libraries, including glib assume these copy semantics on a win32 targets; for example g_setenv / G_OS_WIN32.

Output from simple test application, yet owc is undefined:

msvc/mingw:
1: MYVAR=XXX
2: MYVAR=XXX

owc:
1: MYVAR=XXX
2: MYVAR=

Source:

#include <stdlib.h>
#include <wchar.h>
static void dump(unsigned call)
{
#if defined(__MINGW32__)
   wprintf(L"%u: MYVAR=%ls\n", call, _wgetenv(L"MYVAR")); //mingw sprintf() not msvc; see __USE_MINGW_ANSI_STDIO
#else
    wprintf(L"%u: MYVAR=%s\n", call, _wgetenv(L"MYVAR")); 
#endif
}
static void set()
{
    wchar_t buffer[] = {L"MYVAR=XXX"};
    _wputenv(buffer);  // == buffer locally scoped
    dump(1);
}
int
main()
{
    set();
    dump(2);
    return 0;
}