-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement os.putenv() with setenv() if available #83587
Comments
Currently, os.putenv() is always implemented with putenv(). The problem is that putenv(str) puts directly the string into the environment, the string is not copied. So Python has to keep track of this memory. In Python 3.9, this string is now cleared at Python exit, without unsetting the environment variable which cause bpo-39395 crash. I propose to implement os.putenv() with setenv() if available, which avoids bpo-39395 on platforms providing setenv(). |
setenv() is available on:
It is not available on Windows. |
Maybe use SetEnvironmentVariable() on Windows? |
I didn't know this function. I updated PR 18095. |
Switching to calling The concern that |
This indeed a good argument to continue to use _wputenv. Thank you Eryk, you have saved us from making a mistake. |
I created bpo-39413 "Implement os.unsetenv() on Windows" to prepare work on this issue. But Eryk raised the same concern about CRT: https://bugs.python.org/issue39413#msg360404 I wasn't aware of that :-/
My main motivation to use SetEnvironmentVariableW() on Windows is to avoid bpo-39395. Do you mean that Windows _putenv() is not affected by bpo-39395: Python can safely removes the string to _putenv() just after the call? |
There is also _wputenv_s which affects _spawn, _exec and system. |
Why posix_putenv_garbage was renamed to putenv_dict? |
Windows ucrt copies the buffer that's passed to _[w]putenv. This makes it non-compliant with POSIX but easier to use in this case. Here's an example using ctypes: >>> ucrt = ctypes.CDLL('ucrtbase')
>>> buf = ctypes.create_unicode_buffer('spam=eggs')
>>> ucrt._wputenv(buf)
0 Directly modifying the buffer has no effect on the _wgetenv result: >>> buf[5] = 'a'
>>> ucrt._wgetenv.restype = ctypes.POINTER(ctypes.c_wchar)
>>> ucrt._wgetenv('spam')[:4]
'eggs' Linux putenv complies with POSIX, so changing "eggs" to "aggs" in the buffer does affect the getenv result in Linux. On the other hand, ucrt's [_w]getenv does not copy the environment string. For example:
>>> p2 = ucrt._wgetenv('spam')
>>> p2[:4]
'oggs' [_w]getenv is not thread safe. Even though all calls that access the ucrt environment are internally synchronized on a common lock, accessing the *result* from [_w]getenv still needs to be synchronized with concurrent _[w]putenv calls in a multithreaded process. Better still, use [_w]getenv_s or _[w]dupenv_s, which returns a copy.
The documentation is perhaps misleading. When a variable is set with _[w]putenv[_s], it also sets the variable in the process environment block to stay in sync. This indirectly affects _spawn*, _exec* and system(). common_spawnv (in ucrt\exec\spawnv.cpp), which implements the latter functions, calls CreateProcess with lpEnvironment as NULL (i.e. inherit the current process environment), unless the caller passes a new environment (e.g. envp of spawnve). |
Serhiy:
In bpo-39413, I implemented os.unsetenv() on Windows using SetEnvironmentVariable(), but Eryk reported that SetEnvironmentVariable() does not update the CRT API (_environ, _wenviron, getenv, etc.). So I reverted my change. See bpo-39413 for the details. Eryk:
Thank you for checking manually. I pushed commit 0852c7d to avoid putenv_dict on Windows. |
The initial issue has been fixed, so I close the issue. Big thanks to Eryk Sun for your great help, thanks also Serhiy Storchaka. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: