Earlier quoted context omitted.
> Mutable global state is evil. Friends don’t let friends use mutable global state. Throw away your CPU and RAM then.
And disks. And the cloud. Or basically, you know, computers.
The universe, you mean.
C stdlib isn't threadsafe and even safe Rust didn't save us
31–40 of 370 posts
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#32I wonder why it is so hard for Rust to implement its own safe stdlib independent of C.
How exactly would that help in this situation?
If both Rust and C have independent standard libraries loaded into the same process, each would have an independent set of environment variables. So setting a variable from Rust wouldn't make it visible to the C code, which would break the article's usecase of configuring OpenSSL.
The only real solution is to have the operating system provide a thread-safe way of managing environment variables. Windows does so; but in Linux that's the job of libc, which refuses to provide thread-safety.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#33The whole point of Rust is memory safety, not thread safety...
Rust literally bakes data race safety into the language. While it does not resolve general race conditions, thread safety issues which cause memory unsafety (which an UAF or dangling pointer would be) are very much within its remit.
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#34Yet another person is burned by calling setenv() in a multi-threaded context. There really needs to be a big warning banner on the manpage for setenv() that warns about this because it seems like a far more common problem than you would expect.
The man page says: > POSIX.1 does not require setenv() or unsetenv() to be reentrant. A non-reentrant function cannot be thread safe. In general (for POSIX, libc and many other libraries: if the docs do not explicitly say "this function is thread safe" they are not).
> A non-reentrant function cannot be thread safe.
Actually, a non-reentrant function can be thread-safe. A common example of such a function in libc being malloc().
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#35Mutable global state is evil. Friends don’t let friends use mutable global state. I hate envvars. It’s “the Linux way”. I avoid them like the plague. A++ strong recommend. libc is terrible. The world needs to move on.
libc moved the world into the Information Age
In the same way that Yersinia pestis moved the world into the Renaissance?
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#36Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#37Earlier quoted context omitted.
It's time to move beyond this attitude and make things safe by default. For example, Solaris has a safer version of setenv(). "It is ridiculous that this has been a known problem for so long. It has wasted thousands of hours of people's time, either debugging the problems, or debating what to do about it. We know how to fix the problem." https://www.evanjones.ca/setenv-is-not-thread-safe.html
I am not sure making things safe by default is a good idea. This always comes with a cost. Thats also the reason why basic data types (array, dictionaries, etc) are generally not thread safe… because its usually not needed or handled on a much higher level. Its a different story for languages/environments that are supposed to be safe by default and where you have language features that ensure safety (actors, optional…
The problem with `setenv` is that people expect one process to have one set of environment variables, which is shared across multiple languages running in that process. This implies every language must let its environment variables be managed by a central language-independent library -- and on POSIX systems, that's libc.
So if libc refuses to provide thread-safety, that impacts not just C, but all possible languages (except for those that cannot call into C-libraries; as those don't need to bother synchronizing the environment with libc).
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#38Mutable global state is evil. Friends don’t let friends use mutable global state. I hate envvars. It’s “the Linux way”. I avoid them like the plague. A++ strong recommend. libc is terrible. The world needs to move on.
[deleted]
Re: C stdlib isn't threadsafe and even safe Rust didn't save us
#39Its like a rite of passage to be hit by an environment related bug on linux, which is mysteriously less a problem on other unix's. Which is sorta funny given how pragmatic Linus and the kernel are about fixing POSIX bugs by making them not happen, while glibc is still lagging here decades after people tried to at least make the problem better. Sure there is all the crap around TZ/etc, but simply providing getenv_r() and synchronizing it with setenv() and warning during compile/link on getenv() would have killed much of the problem. Nevermind, actually doing a COW style system where the env pointer(s) are read only. Instead the problem is pushed to the individual application, which is a huge mistake, because application writers are rarely aware of what their dependencies are doing. Which is the situation I found myself in many many years ago. The closed source library vendor, at the time, told us to stop using that toy unix clone (linux).