undefined | Better HN

story

0 pointskelnos1y ago0 comments

That doesn't solve anything. You could be using a library (perhaps a closed-source one) that doesn't use these hypothetical lockenv()/unlockenv() functions.

This needs to be fixed inside libc, but there's no way to do so completely without breaking backward-compatibility.

0 comments

tsimionescu1y ago

Yes, I was talking about fixes inside libc. The poster above was claiming it can't be done inside libc. And the lockvenv/unlockvenv functions I was mentioning were meant to exist besides the internal locking inside setenv/getenv. They would only be used if you needed transactional access (a combination of setting/getting multiple env vars atomically).

xxs1y ago

using copy on write would be easier (and more performant), along with getenv_r. POSIX requires not to copy the data which makes the entire mutex/lock or CoW pointless. Of course, there will be the mandatory mentioning of "extern char *environ;"[0]. That returns are raw C strings as you can find them.

What could work is per thread env. changes - but that's not likely to happen

[0]: https://linux.die.net/man/3/environ