4 ms·
The discussion is only relevant for a shared unguarded resource (the env) modified and read by multiple threads. Single threaded operations are just fine.
by 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”