Ticket History #2636: replace all calls to getenv()/setenv() with Get/SetEnvironmentVariable on Windows

Can this be done with a macro in win-mac.h?

On the plus side, that'll likely be a thread-safe interface, compared
with the UNIX one (if setenv is used). Perhaps we should modify our
uses of getenv to call a helper function which returns us a string in
allocated storage; then that helper function could use either getenv or
GetEnvironmentVariable, and in the getenv case, while it still wouldn't
be thread-safe, it would reduce the window of exposure somewhat.

Ken

On Wed, Jul 14, 2004 at 04:11:01PM -0400, Jeffrey Altman [Kermit Project] via RT wrote:

Yes.


The krb5 library doesn't use setenv()/putenv() and I think it's safe to
assume that getenv() is always safe with respect to other concurrent
calls to getenv(), so the krb5 lib should not worry about getenv()'s
thread-safety (there's nothing it could w.r.t. other threads that do a
setenv() outside the context of krb5).

Nico
--

I would like to bring this topic back to the foreground.
As a refresher, the Kerberos libraries and applications make
extensive use of getenv() and setenv() for manipulating the
environment. On Windows this is problem because the getenv
and setenv CRT functions do not access the real environment
of the application. Instead they manipulate a private
implementation of environ[].

There are several mechanisms via which we can address this
issue. Here is a proposal for implementation:

We leave the POSIX systems alone and for Windows implement
new support functions:

const char * win32_getenv(const char * var)
int win32_setenv(const char *var, const char *value)

and a macro

free_envstr(str)

win32_getenv() would be implemented in terms of the Win32
GetEnvironmentVariable API. This API can be called in two
ways. First it can be used to obtain the required buffer
size and secondly to obtain the value in a provided buffer.
win32_getenv() would determine the appropriate buffer size,
allocate the buffer with malloc(), and then obtain the value
and return the buffer. This buffer would then need to be
freed by the caller.

win32_setenv() would take a variable name and value and
pass them to the SetEnvironmentVariable API

On Windows, the free_envstr macro would call an appropriate
function to free the allocated memory.

On POSIX systems, the free_envstr macro would be a no-op.

What do people think?

Jeffrey Altman