3 ms·
Interestingly, Windows developers made much better choices back in the 1990-s. GetEnvironmentStrings() API comes with the FreeEnvironmentStrings() counterpart.
by Const-me 3y ago
Interestingly, Windows developers made much better choices back in the 1990-s.
GetEnvironmentStrings() API comes with the FreeEnvironmentStrings() counterpart. Whoever calls GetEnvironmentStrings() to get the entire environment is then responsible to call FreeEnvironmentStrings(), which allows thread-safe GetEnvironmentStrings() API.
GetEnvironmentVariable() API is even simpler, it doesn’t return a pointer, instead it fills a caller-provided buffer.
- NekkoDroid 3y agoGetEnvironmentVariable() also has a subtle problem from what I can see: You first check how big the buffer has to be and in the second call you actually fill out the buffer, which allows for the variable to change between those 2 calls (I guess it's a variant of the time-of-check time-of-use race condition). There is getenv_s that doesn't have this problem to my knowledge, but it also doesn't exactly allow you to control the allocation of the memory (how important that is in cases like this is a different question)
- Const-me 3y agoIt seems the getenv_s and GetEnvironmentVariable API functions are 100% equivalent; the API is only slightly different. When you don’t know the length of the variable you query, you guessed wrong on the first attempt, and other threads are changing the environment in the background, you might need 3 of even more calls to either function (passing longer output buffers) to successfully retrieve the complete variable.
- deleted 3y ago[deleted]
- NekkoDroid 3y agoYou are right, I mixed up my functions. What I actually meant was _dupenv_s