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