Yes it is, if you program application software for Linux (and your other two supported platforms are Windows and macOS, as is the case for OP and their colleague who appear to work for Valve, supporting Steam)

And the reason the colleague dubs it the worst has nothing to do with its specification in POSIX (which doesn't require the function to be thread-safe but also doesn't prevent it from being made thread-safe), but rather its specific implementation in glibc, which is the C library in use on all the Linux distributions that Valve support Steam on and all are equally dubbed as "Linux"

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.

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.

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.

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.

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.