3 ms·

Technically, this is a GNU libc limitation. A libc _could_ make this thread-safe. Languages like go just implement this feature internally and don't have this

Technically, this is a GNU libc limitation. A libc _could_ make this thread-safe. Languages like go just implement this feature internally and don't have this limitation. The limitation is contemplated in POSIX itself; from the posix documentation: > The setenv() function need not be thread-safe.

deleted 2y ago
[deleted]
deathanatos 2y ago
I think you get thread-safety and memory leaks (the article alludes to macOS taking this approach), or it's unsafe but doesn't leak. But that is inherent in the API, as specified by POSIX: setenv must necessarily either invalidate the pointer returned by getenv (which is cannot do safely) or leak it. Perhaps the leak is "better", in at least there won't be non-OOM crashes, but it still leaves a bad taste in one's mouth. For a long running program like Steam (that is for some odd reason calling setenv…?) … I'm not sure which is better. Better would be not calling setenv, which it sounds like they've worked on.
- jandrese 2y ago
  I would be happy if getenv() called strdup() on the value and returned that. It would cause loads of minor memory leaks and maybe a handful of serious ones, but they should be reasonably easy to clean up and would avoid returning pointers to mutable private data.
  - deathanatos 2y ago
    It'd be an API change, sort of? Although POSIX doesn't seem to say anything about ownership of the pointer, beyond thou-shalt-not modify the data it points to. Doesn't seem to specify calling free as valid or invalid. But honestly, it seems like one might as well do exactly that (strdup & return)? At worst, nothing calls free(), and it is equivalent to the macOS strategy of "just leak the memory" to make it threadsafe. But at best, a program could #ifdef its way into "oh, this semi-sorta-nonstandard-behavior on this particular OS" and call free(), getting both a thread-safe & non-leaking implementation.
  - WhyNotHugo 2y ago
    There are a lot of situations where allocating is not acceptable (e.g.: critical applications that don't heap-allocate in order to ensure they never OOM). Of course, we could have just getenvdup() which does what you just said. Let each application chose which variant is best for them: leaking, or thread-unsafe.

deleted 2y ago

[deleted]

deathanatos 2y ago

I think you get thread-safety and memory leaks (the article alludes to macOS taking this approach), or it's unsafe but doesn't leak. But that is inherent in the API, as specified by POSIX: setenv must necessarily either invalidate the pointer returned by getenv (which is cannot do safely) or leak it. Perhaps the leak is "better", in at least there won't be non-OOM crashes, but it still leaves a bad taste in one's mouth. For a long running program like Steam (that is for some odd reason calling setenv…?) … I'm not sure which is better. Better would be not calling setenv, which it sounds like they've worked on.

jandrese 2y ago
I would be happy if getenv() called strdup() on the value and returned that. It would cause loads of minor memory leaks and maybe a handful of serious ones, but they should be reasonably easy to clean up and would avoid returning pointers to mutable private data.
- deathanatos 2y ago
  It'd be an API change, sort of? Although POSIX doesn't seem to say anything about ownership of the pointer, beyond thou-shalt-not modify the data it points to. Doesn't seem to specify calling free as valid or invalid. But honestly, it seems like one might as well do exactly that (strdup & return)? At worst, nothing calls free(), and it is equivalent to the macOS strategy of "just leak the memory" to make it threadsafe. But at best, a program could #ifdef its way into "oh, this semi-sorta-nonstandard-behavior on this particular OS" and call free(), getting both a thread-safe & non-leaking implementation.
- WhyNotHugo 2y ago
  There are a lot of situations where allocating is not acceptable (e.g.: critical applications that don't heap-allocate in order to ensure they never OOM). Of course, we could have just getenvdup() which does what you just said. Let each application chose which variant is best for them: leaking, or thread-unsafe.