Thanks for posting this Tom — really good paper input :) I’ve indeed started drafting an outline and this is *way harder/worse* than I hoped. I *think* I agree with most everything that’s been said so far — here’s my summary so of directional thoughts so far:

1) It is a non-negotiable requirement for std::process — a different proposal I’ll be restarting — to write the environment before launching a child process — Ville and Jake's points. There simply is no standard way to do it currently — putenv, unsetenv is posix only. No matter what I think this should be fixed.

2) In my survey of other languages, basically none of them can really solve the thread safety issues. Why? Because it’s not supported by the platforms -- so I think it's literally not possible. You can have 3 Rust threads all mutexed on shared environment while a C thread does whatever it wants and messes them up. Their documentation is very clear on this point — read Jake’s points.

So as Jonathan indicates we could create an api that does a snapshot of the environment that can be accesses safely — but of course that won’t be accurate if another thread changes it. To my mind, this doesn’t fix the problem. Unfortunately this is unprotected global state and short of a thread safe platform api c++ probably can’t fix it. So sure, we could provide some API that limits a C++ program from stomping on itself if it’s all C++ — maybe that’s worth it so that c++ libraries and user code could count on that facility? Still not going to fix threads in C or other languages from bad interactions with C++ threads.

3) Aside from the obvious pointer usability issues, getenv isn’t a great way to ‘discover’ what’s actually set in the environment. Keeping in mind that often — ‘not set’ has meaning. Currently you'd need to ask one a a time. I think there’s some value to a range based facility to grab a set of variables (even a post on reddit this week of a lib that can grab a filtered set).

I’ll now assume all the respondents fo this thread will be early feedback candidates :)

Jeff

> On Jan 1, 2023, at 7:16 PM, Jake Arkinstall <jake.arkinstall_at_[hidden]> wrote:
>
> On Mon, 2 Jan 2023, 00:36 Corentin Jabot via Lib-Ext, <lib-ext_at_[hidden] <mailto:lib-ext_at_[hidden]>> wrote:
> (putenv is not a system facility, it has no effect whatsoever on the system, in only affect the current process)
>
> And, I believe, processes spawned from the current process, such as via fork. It also has an effect on std::system calls. I don't use this functionality but I imagine that, if I did, I'd want the ability to control its environment.
>
> Environment variables are predominantly used as input - even more so in recent years - but they can be used as "output" too. Otherwise they wouldn't be provided to be read as input to begin with.
>
> So if we want to be able to launch processes but don't want to mutate the environment, we need a mechanism to pass environment variables to the processes.
>
> It would also make sense that, if we must have an immutable global pseudo-environment, we allow transformations that provide new pseudo-environments that we can pass around. At the very least, std::system should gain an overload that accepts a pseudo-environment that results from this.
>
> Are we providing a way to query the environment or a global map of strings?
>
> The above being said, I would still find it surprising if a call to putenv didn't change the output from something that is supposed to abstract and modernise environment access. I imagine many others would.
>
> I would also find it surprising if something that is supposed to abstract and modernise environment access only provided read-only functionality, especially if the justification of that was based on the premise that reading and writing isn't thread safe. Anyone wanting to write would be forced to use setenv or putenv anyway, and the problem still emerges.
>
> Or, more generally:
>
> - We have an unsafe thing.
> - We make a safe alternative that is incomplete because some parts weren't possible to to in a safe manner
> - We still have the unsafe thing because we don't break things for users.
> - Therefore we still have an unsafe thing.
>
> We can only add footguns. We can't take them away. I worry that trying to avoid footguns by pushing users to use the old ones, and then making any kind of decision based on the wrong assumption that the footgun is dealt with, can only lead to new footguns.
>
> In the case of environment variables, this is just the nature of global state managed by the operating system. The safety is at the hands of the operating system. Rust has its own battles with it, too - and recent ones, resulting from CVEs relating to setenv safety. https://github.com/rust-lang/rust/issues/90308 <https://github.com/rust-lang/rust/issues/90308> tentatively concludes with removing the safety guarantee of setting environment variables. We don't have a concept of safety in the language, but I feel that avoiding the functionality altogether for that reason doesn't make sense.
>
> So to actually get to your question, I think storing state and hoping existing code doesn't change it via the features already available to it is a bad move, and I think it should be the former: a way to query the current environment.
>
> If, however, the alternate path is chosen, then it needs to be named well. Environment variables are mutable. If what the user is querying is actually the environment variables at startup, then it should be named accordingly to avoid confusion.