3 ms·

> Exposing global mutable access to something and providing no thread safe version counts as broken in my book. Your book may differ. Please show me from which

by rewmie 3y ago

> Exposing global mutable access to something and providing no thread safe version counts as broken in my book. Your book may differ. Please show me from which book you got the idea that env variables are expected to change throughout the lifetime of a process.

necovek 3y ago
It seems they are arguing that setenv should not exist in the first place: the fact it exists suggests it can and should be used, and thus not be a footgun.
- orwin 3y ago
  > the fact it exists suggests it can and should be used I think most people argue about that. Just because it exists doesn't mean it should be used imho. I've used it exactly once, and that was a school exercise where I had to write a Posix shell (most of a posix shell actually), including built-ins. I do not see another use case tbh.
- jstimpfle 3y ago
  > can and should be used, and thus not be a footgun It can and should be used in the cases where it makes sense, with the restrictions that are documented. It's an API that is fundamentally not thread-safe, you can not use it "safely" (in the modern sense of using it after a lobotomy, in any way that the compiler allows) in a multi-threaded context. There are other such APIs, and if those APIs were removed it would hurt a lot of old software that is running perfectly fine.
jeroenhd 3y ago
> Please show me from which book you got the idea that env variables are expected to change throughout the lifetime of a process. POSIX specifies two functions that alter environment variables. It could've specified that env variables are supposed to be mapped into a read-only memory page where available to indicate that they shouldn't be altered, but it didn't, and instead provided an explicit read/write system.
- rewmie 3y ago
  > POSIX specifies two functions that alter environment variables. The same POSIX spec you're citing also states in no ambiguous terms that setenv is not thread-safe. It's pointless to quote a section of a spec to try to justify failing to comply with the very same section of the very same spec.
  - jeroenhd 3y ago
    I'm not saying it doesn't. I'm just saying the spec indicates that environment variables can change during runtime. The spec is the problem in my opinion, you can't implement it in a way that doesn't introduce footguns.

by rewmie 3y ago

necovek 3y ago

It seems they are arguing that setenv should not exist in the first place: the fact it exists suggests it can and should be used, and thus not be a footgun.

orwin 3y ago
> the fact it exists suggests it can and should be used I think most people argue about that. Just because it exists doesn't mean it should be used imho. I've used it exactly once, and that was a school exercise where I had to write a Posix shell (most of a posix shell actually), including built-ins. I do not see another use case tbh.
jstimpfle 3y ago
> can and should be used, and thus not be a footgun It can and should be used in the cases where it makes sense, with the restrictions that are documented. It's an API that is fundamentally not thread-safe, you can not use it "safely" (in the modern sense of using it after a lobotomy, in any way that the compiler allows) in a multi-threaded context. There are other such APIs, and if those APIs were removed it would hurt a lot of old software that is running perfectly fine.

jeroenhd 3y ago

> Please show me from which book you got the idea that env variables are expected to change throughout the lifetime of a process. POSIX specifies two functions that alter environment variables. It could've specified that env variables are supposed to be mapped into a read-only memory page where available to indicate that they shouldn't be altered, but it didn't, and instead provided an explicit read/write system.

rewmie 3y ago
> POSIX specifies two functions that alter environment variables. The same POSIX spec you're citing also states in no ambiguous terms that setenv is not thread-safe. It's pointless to quote a section of a spec to try to justify failing to comply with the very same section of the very same spec.
- jeroenhd 3y ago
  I'm not saying it doesn't. I'm just saying the spec indicates that environment variables can change during runtime. The spec is the problem in my opinion, you can't implement it in a way that doesn't introduce footguns.