4 ms·

Even if C stdlib maintainers are resistant against making setenv multi-thread safe, at a minimum there should be a new alternative thread-safe API defined, whet

Even if C stdlib maintainers are resistant against making setenv multi-thread safe, at a minimum there should be a new alternative thread-safe API defined, whether within POSIX or defining a defacto standard and forcing POSIX to adopt it over time. If instead of explaining why nothing could be done was spent fixing this problem, a new thread-safe API could have replaced the old setenv which could have been deprecated and removed from many software projects. I'm also not convinced by Musl's maintainer that it can't be fixed within Musl considering glibc is making changes to make this a non-issue.

panzi 2y ago
Guess that would also require some locking for all the exec() functions that don't take the environment as a parameter or that search PATH for the executable.
usefulcat 2y ago
The biggest problem is not the absence of a thread safe API, it's the existence of this: extern char **environ; As long as environ is publicly accessible, there's no guarantee that setenv and getenv will be used at all, since they're not necessary. If you're willing to get rid of environ, it's pretty trivial to make setenv and getenv thread safe. If not, then it's impossible, although one could still argue that making setenv and getenv thread safe is at least an improvement, even if it's not a complete solution (aka don't let the perfect be the enemy of the good).
- vlovich123 2y ago
  > aka don't let the perfect be the enemy of the good Exactly my point. Over time *environ would disappear, at least from the major software projects that everyone uses (assuming it's even in use in them in the first place).
  - IshKebab 2y ago
    Yeah I don't think I've ever seen a single use of it. However I just checked on grep.app and at least a few big softwares use it - git, nginx, Postgresql, neovim, etc, which suggests that setenv/getenv is not sufficient.
  - aragilar 2y ago
    That still doesn't mean getenv would be safe. Unless you know nothing uses **environ (e.g. by breaking the ABI, which no-one will do because it'll break everything), you can't rely on getenv being safe.
    - pornel 2y ago
      There should be locking getters/setters for the environ, and all users should switch to them. Yes, it will take a long time, and some users will complain it doesn't work on their PDP-11, but the problem will never be solved if there's no migration path to a safe solution.
davidt84 2y ago
I'm not convinced by you that you know more than the experts who have determined there is no backwards-compatible way to fix this.
- vlovich123 2y ago
  I'll take existence proofs [1] over personal insults but YMMV. You also may want to be careful assuming the expertise of people on this forum. Some people here are quite technical. [1] https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6fca5e2d1f13f65685c61 https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6f...
  - davidt84 2y ago
    That isn't thread safe, it's safER. I am also quite technical, thanks.
    - AdelaideSimone 2y ago
      [flagged]

panzi 2y ago

Guess that would also require some locking for all the exec() functions that don't take the environment as a parameter or that search PATH for the executable.

usefulcat 2y ago

The biggest problem is not the absence of a thread safe API, it's the existence of this: extern char **environ; As long as environ is publicly accessible, there's no guarantee that setenv and getenv will be used at all, since they're not necessary. If you're willing to get rid of environ, it's pretty trivial to make setenv and getenv thread safe. If not, then it's impossible, although one could still argue that making setenv and getenv thread safe is at least an improvement, even if it's not a complete solution (aka don't let the perfect be the enemy of the good).

vlovich123 2y ago
> aka don't let the perfect be the enemy of the good Exactly my point. Over time *environ would disappear, at least from the major software projects that everyone uses (assuming it's even in use in them in the first place).
- IshKebab 2y ago
  Yeah I don't think I've ever seen a single use of it. However I just checked on grep.app and at least a few big softwares use it - git, nginx, Postgresql, neovim, etc, which suggests that setenv/getenv is not sufficient.
- aragilar 2y ago
  That still doesn't mean getenv would be safe. Unless you know nothing uses **environ (e.g. by breaking the ABI, which no-one will do because it'll break everything), you can't rely on getenv being safe.
  - pornel 2y ago
    There should be locking getters/setters for the environ, and all users should switch to them. Yes, it will take a long time, and some users will complain it doesn't work on their PDP-11, but the problem will never be solved if there's no migration path to a safe solution.

davidt84 2y ago

I'm not convinced by you that you know more than the experts who have determined there is no backwards-compatible way to fix this.

vlovich123 2y ago
I'll take existence proofs [1] over personal insults but YMMV. You also may want to be careful assuming the expertise of people on this forum. Some people here are quite technical. [1] https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6fca5e2d1f13f65685c61 https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6f...
- davidt84 2y ago
  That isn't thread safe, it's safER. I am also quite technical, thanks.
  - AdelaideSimone 2y ago
    [flagged]