On Mon, Jan 2, 2023 at 1:19 AM Jonathan Wakely via SG16 <
sg16_at_[hidden]> wrote:

>
>
> On Sun, 1 Jan 2023, 23:20 Ville Voutilainen via Lib-Ext, <
> lib-ext_at_[hidden]> wrote:
>
>> On Mon, 2 Jan 2023 at 00:51, Tom Honermann via Lib-Ext
>> <lib-ext_at_[hidden]> 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
>> idealistic
>> 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
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>