C++ Logo

sg16

Advanced search

Re: [isocpp-lib-ext] std::environment

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Mon, 2 Jan 2023 00:19:18 +0000
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.

Received on 2023-01-02 00:19:32