GNU bug report logs - #19874
25.0.50; encode-time not working as expected

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 19874 <at> debbugs.gnu.org, Ashish SHUKLA <ashish.is <at> lostca.se>
Subject: bug#19874: 25.0.50; encode-time not working as expected
Date: Fri, 27 Feb 2015 15:54:01 -0800

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.