set-environment-variable Lassi Kortela 05 Dec 2019 00:18 UTC
Re: set-environment-variable John Cowan 05 Dec 2019 19:47 UTC
Re: set-environment-variable hga@xxxxxx 06 Dec 2019 00:28 UTC
Re: set-environment-variable Lassi Kortela 06 Dec 2019 09:55 UTC
Re: set-environment-variable John Cowan 06 Dec 2019 13:20 UTC
Re: set-environment-variable Lassi Kortela 06 Dec 2019 13:53 UTC
Re: set-environment-variable John Cowan 06 Dec 2019 17:51 UTC
Re: set-environment-variable Arthur A. Gleckler 06 Dec 2019 18:45 UTC
Re: set-environment-variable Lassi Kortela 06 Dec 2019 19:00 UTC
Re: set-environment-variable Lassi Kortela 06 Dec 2019 20:40 UTC
Re: set-environment-variable hga@xxxxxx 07 Dec 2019 15:06 UTC
Re: set-environment-variable Lassi Kortela 07 Dec 2019 16:14 UTC
Re: set-environment-variable Lassi Kortela 07 Dec 2019 16:23 UTC
Re: set-environment-variable hga@xxxxxx 07 Dec 2019 16:29 UTC
Re: set-environment-variable John Cowan 07 Dec 2019 17:31 UTC
Re: set-environment-variable Lassi Kortela 07 Dec 2019 20:12 UTC
Is set-environment-variable needed after all? Lassi Kortela 07 Dec 2019 20:15 UTC
Re: Is set-environment-variable needed after all? John Cowan 07 Dec 2019 21:12 UTC
Re: Is set-environment-variable needed after all? Lassi Kortela 08 Dec 2019 19:36 UTC
Re: Is set-environment-variable needed after all? hga@xxxxxx 08 Dec 2019 20:07 UTC
Re: Is set-environment-variable needed after all? Lassi Kortela 09 Dec 2019 11:00 UTC
Re: Is set-environment-variable needed after all? Duy Nguyen 09 Dec 2019 03:51 UTC
Re: Is set-environment-variable needed after all? John Cowan 09 Dec 2019 04:20 UTC
Re: Is set-environment-variable needed after all? Lassi Kortela 09 Dec 2019 10:38 UTC
Re: Is set-environment-variable needed after all? Lassi Kortela 09 Dec 2019 10:41 UTC
Re: Is set-environment-variable needed after all? Duy Nguyen 09 Dec 2019 10:45 UTC
Re: Is set-environment-variable needed after all? Lassi Kortela 09 Dec 2019 10:49 UTC
Re: Is set-environment-variable needed after all? John Cowan 09 Dec 2019 19:35 UTC
Re: Is set-environment-variable needed after all? Lassi Kortela 09 Dec 2019 19:45 UTC

Re: set-environment-variable Lassi Kortela 07 Dec 2019 20:12 UTC

> 1) They inherently and unavoidably leak memory, even though setenv()
> copies its arguments before putting them in the environment.  The
> problem is created by the existence of putenv(), which is required by
> both ISO C and Posix.  Putenv() deliberately does *not* copy its
> argument; rather, the argument becomes part of the environment data
> structure.  This means putenv() by itself is deterministic: if you
> unsetenv() the variable, or if you are about to putenv() it again, the
> memory used by the previous putenv can be free()d, or can even be a
> stack variable if you are careful.
>
> But having both putenv() and setenv() means that setenv() and unsetenv()
> *cannot free* the entry they are about to remove, because it may have
> been inserted by putenv.  So if you are using setenv() freely, you have
> a permanent (though usually small) memory leak.

I've never thought of that.

OpenBSD libc (which is known for its attention to correctness) never
frees any strings that are part of the environment. None of setenv(),
putenv() and unsetenv() call free() on any string they remove from the
environ array. environ itself it reallocarray()'d as needed.

<https://github.com/openbsd/src/blob/master/lib/libc/stdlib/setenv.c>

Not sure how much the memory leak matters. If an implementation wanted
to go to a ton of effort, it could keep a list of pointers to "putenv()
strings managed by Scheme" and the delete-environment-variable! could
check whether it's one of those.

> 2) The only reasons to modify the environment rather than changing a
> variable initialized from the environment are these:
>
> 2a) to affect the behavior of some other part of the process, typically
> some library (as TZ affects the time zone library).  The trouble here is
> that most such libraries do *not* expect these variables to change and
> don't check whether they should mutate their internal view, so changing
> the environment is likely to be ineffectual.  (Fortunately, the Olson
> time zone library provides a way to change the timezone directly without
> changing the environment.)
>
> 2b) to pass a modified environment to a subprocess.  But we can already
> get the whole environment as an alist, and the ProcessesCowan pre-SRFI
> accepts an alist and synthesizes a replacement environment from it.
> Leaks don't matter here because memory will be discarded by the execve()
> call,

Maybe. setenv() tends to be a "set and forget" thing done at the start
of the program. It also potentially causes problems in multi-threaded
implementations. The text I wrote for the SRFI has some language to warn
about that but it's not ideal to lock the environment array separately
for each read and write operation.