exec-path-list rationale Lassi Kortela (29 Jul 2019 07:03 UTC)
Re: Simplicity of timespec section, and exec-path-list rationale Lassi Kortela (31 Jul 2019 14:47 UTC)

Re: Simplicity of timespec section, and exec-path-list rationale Lassi Kortela 31 Jul 2019 14:47 UTC

>     They are just a char** array in memory. You can even point 'environ' to
>     a completely different array and it works fine.
>
> Ah, I didn't realize that.  I go back to a day when the environment
> variables had to be stored in a fixed part of the address space, like
> the program arguments, and if you were out of room in that fixed space,
> you lost.

Cool. I keep forgetting the past. That explains a lot.

For reference, here's the current implementation of setenv() and co from
FreeBSD's libc:
<https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/getenv.c>.
It uses ordinary realloc to work with the string arrays. After all the
gymnastics are done, it just sets `environ` to the new array.

> Then let's kill it, and ask people to use (string-split (getenv "PATH")
> colon?) instead.

Thanks for listening.

On Windows, semicolon is the PATH separator. Even if we don't provide a
`getenv` procedure in this SRFI, perhaps we should provide a string
constant that gives the path separator. `path-list-separator`?