3 ms·

Yes, I’m not saying shell scripts are affected, merely using them as an example to answer the question “Why do any of these [env vars] need to change at runtime

• xxs 3y ago
  The discussion is only relevant for a shared unguarded resource (the env) modified and read by multiple threads. Single threaded operations are just fine.
  • Someone 3y ago
    > Single threaded operations are just fine. Sort of. https://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...: “The returned string pointer might be invalidated or the string content might be overwritten by a subsequent call to getenv()” There’s little you can do with a broken API, so Linux has that ‘feature’, too. https://man7.org/linux/man-pages/man3/getenv.3.html https://man7.org/linux/man-pages/man3/getenv.3.html: “The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3).” FreeBSD chooses to leak memory, instead. https://man.freebsd.org/cgi/man.cgi?getenv(3) https://man.freebsd.org/cgi/man.cgi?getenv(3): “Successive calls to setenv() that assign a larger-sized value than any previous value to the same name will result in a memory leak. The FreeBSD semantics for this function (namely, that the contents of value are copied and that old values remain accessible indefinitely) make this bug unavoidable”