You can't guarantee that whatever libraries you pull in use the same mutex as you though.

[delayed]

I'm not sure I understand the question.

If you are writing, say, a GUI application, and use GTK, GTK may use getenv (without your mutexes, of course) at the same time you call setenv in another thread, potentially crashing your entire application if you are unlucky.

Who doesn't? libc itself calls getenv when getting system time: https://news.ycombinator.com/item?id=38344224

You may have a mutex on getenv/setenv, like the Rust stdlib does, but when libc doesn't look at that mutex, even on the read side, you run into UB.

So the next step is never calling into seemingly innocent libc functions in safe code (which you have to enforce on your dependencies as well), implementing safe alternatives to a good chunk of libc (and making sure your dependencies use those), to cordon off anything that looks at the environment. This makes a good chunk of POSIX functionality useless.

OK thank you for the explanation.. This makes more more scared to bring in libraries :(

I thought they were talking about inside the libc implementation. Though, if that was done and people call getenv from async contexts, it could deadlock.