|
From: | Paul Eggert |
Subject: | bug#19874: 25.0.50; encode-time not working as expected |
Date: | Fri, 27 Feb 2015 15:54:01 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |