4 ms·
I think the problem is in setenv(3), not getenv(3). Reading shared global state is okay as long as it is not mutable. If someone relies on modifying environment
by r2vcap 3y ago
I think the problem is in setenv(3), not getenv(3). Reading shared global state is okay as long as it is not mutable. If someone relies on modifying environment variables, one should use execve(3), not setenv.
- metadat 3y agoFor those who, like me, are a bit rusty on the man memorization: execve(3): https://linux.die.net/man/3/execve https://linux.die.net/man/3/execve
- Too 3y agoExactly. Setting environment variables while a program is running is a terrible idea. Thread safe or not. A lot of code, for good reasons, assume envvars are constants set before the program started and caches computations based on them, read config files and so on. The fact that they are essentially global variables should be enough to deter usage of them.
- chriswarbo 3y ago> The fact that they are essentially global variables should be enough to deter usage of them Env var behaviour is much closer to dynamic variables, rather than global variables (which I argue at http://www.chriswarbo.net/blog/2021-04-08-env_vars.html http://www.chriswarbo.net/blog/2021-04-08-env_vars.html ) Either way, I agree that mutating them is usually a bad idea; though I find them very good for constant (or dynamically-bound) config.
- cryptonector 3y agoIt can be made safe: https://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libc/port/gen/getenv.c?r=60b81b86#48 https://src.illumos.org/source/xref/illumos-gate/usr/src/lib...