On 02/27/2015 09:33 AM, Wolfgang Jenkner wrote:
> IIUC, the standard explicitly permits the FreeBSD behaviour, so the
> program above does not seem to be conforming:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html
>
> 	If the application switches to a complete new environment by
> 	assigning a new value to environ, this can be detected by
> 	getenv(), setenv(), unsetenv(), or putenv() and the
> 	implementation can at that point reinitialize based on the new
> 	environment. (This may include copying the environment strings
> 	into a new array and assigning environ to point to it.)

No, because that part of the rationale is not talking about the buggy FreeBSD 
behavior.  Although the test program does assign a new value to environ, that's 
not a problem because everything still works: 'setenv' reinitializes based on 
the new environment, as it's allowed to do.  The problem doesn't occur until 
after the assignment "env1[0] = 'x'", and this is a different matter.

As the getenv rationale points out, "conforming applications are required not to 
directly modify the pointers to which /environ/ points", and it appears that's 
the restriction you're thinking about.  However, the test program obeys this 
restriction.  Although the restriction applies to environ[0], environ[1], etc., 
it does not apply to environ[0][0], environ[0][1], etc.  Programs are allowed to 
change the char objects in environ strings that they supply (either via putenv, 
or directly by switching to a complete new environment), and Emacs relies on 
this, as does the test program.

The reason Emacs relies on this, by the way, is that Emacs requires a 
thread-safe way to set the TZ environment variable without dumping core if 
different threads invoke 'setenv' and/or 'unsetenv' and/or 'putenv' at about the 
same time.  This was a real problem in Emacs before it started using the current 
approach of modifying the environment's TZ value in-place (or zapping its name 
to unset TZ). Please see:

http://bugs.gnu.org/8705