On Mon, Jan 2, 2023 at 1:19 AM Jonathan Wakely via SG16 <sg16@lists.isocpp.org> wrote:

On Sun, 1 Jan 2023, 23:20 Ville Voutilainen via Lib-Ext, <lib-ext@lists.isocpp.org> wrote:
On Mon, 2 Jan 2023 at 00:51, Tom Honermann via Lib-Ext
<lib-ext@lists.isocpp.org> wrote:
> Happy New Year!
> Jeff Garland recently indicated that he is intending to restart work on std::environment; an improved facility for interaction with environment variables. The following describes relevant history that I'm aware of and my own thoughts and preferences for a future proposal.
> History
> Previous discussions have been in the context of these two papers:
> P1275: Desert Sessions: Improving hostile environment interactions
> P1750: A Proposal to Add Process Management to the C++ Standard Library
> Records of previous discussion are available at the links below. Relevant std::environment related design polls are included inline (other polls are omitted but can be found in the linked records of discussion).
> 2018-11-07, San Diego, LEWGI discussion of P1275.
> POLL: std::environment should be immutable
> Attendance: 11
> SF
> F
> N
> A
> SA
> 4
> 4
> 1
> 1
> 1

This poll defeats the purpose of the facility. If I'll get a portable
replacement for getenv(), I shouldn't need to use putenv() either any
more. We should expose the capabilities of the system-specific
facilities we wrap into a portable API, not hide them behind
APIs that don't allow something like setting an environment variable.
The environment is already global mutable state, and it's not
the job of std::environment to pretend otherwise, if you ask me. This
poll is also suggesting that we leave room for a language underneath
C++ here, and we shouldn't do that, in principle.

The fact it's global mutable state makes it effectively unusable in library code. You can't even access it safely if the program might have multiple threads, because another thread could be modifying the environment. I think it's a reasonable position to take that we should not make it easier to make such modifications, even though they're already possible via putenv.

If we could provide read-only *race-free* access to the environment (even if it's a snapshot of the env at startup and doesn't reflect later changes made via putenv) then that seems very attractive. I would much rather be able to access the environment safely as read-only than be able read and write unsafely.

If we can't provide that, then I am fairly uninterested in a new API for doing unsafe things in a new way.

Moreover, the ability to modify the view over the environment makes the thing hard to use, if not pointless.
If someone overrides the value of an environment variable, there is no (easy/portable/reliable) way to get to the original value (which was put there by the parent process).
This is an issue for example with libraries overwriting "LC_XXX", thereby making them unusable to determine how to communicate with the parent process.

(putenv is not a system facility, it has no effect whatsoever on the system, in only affect the current process)

Are we providing a way to query the environment or a global map of strings?

SG16 mailing list