Bruno Haible <[email protected]> writes:
> This is justified by POSIX [1], which says
> "These strings have the form name=value"
Yes, but it seems like better behavior to just make the relevant
functions continue on to the next environment variable. It looks like
the linker used to crash with a bad environment, which was why it is the
way it is currently [2].
I guess there is a lot of undefined behavior with respect to
environment variables. That page also says [1]:
If more than one string in an environment of a process has the same
name, the consequences are undefined.
As far as I am aware, all implementations will insert the duplicate at
the end of ENVIRON and just return the first one when getenv is called.
Doing the following is also undefined behavior:
static char *new_environ[] = { "HOME=/home/collin", NULL };
environ = new_environ;
puts (getenv ("HOME"));
This is mentioned in the POSIX.1-2024 getenv specification [3]:
Conforming applications are required not to directly modify the
pointers to which environ points, but to use only the setenv(),
unsetenv(), and putenv() functions, or assignment to environ itself,
to manipulate the process environment. This constraint allows the
implementation to properly manage the memory it allocates.
I wasn't actually aware of that text until now. I am more familiar with
the POSIX.1-2004 wording [4]:
If the application modifies environ or the pointers to which it
points, the behavior of getenv() is undefined.
But, I am not aware of anywhere this is problematic. Certainly a
conformant implementation of 'env -i' would be much slower than it needs
to be because of the repeated calls to unsetenv().
> In the patch: s/it's/its/
That is embarrassing. :)
Collin
[1] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html
[2]
https://github.com/freebsd/freebsd-src/commit/56a3273e0b0a4026f05a7354869ae71ec18c1a32
[3] https://pubs.opengroup.org/onlinepubs/9799919799/functions/getenv.html
[4] https://pubs.opengroup.org/onlinepubs/009696899/functions/getenv.html
