bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert <eggert@cs.ucla.edu>]

Wolfgang Jenkner wrote:
> I was simply thinking about something like
>
> 	q = environ_tmp;
> 	for (p = environ; *p; p++, q++)
> 		*q = strdup(*p);
> 	environ = environ_tmp;

The behavior of getenv, setenv, etc. are undefined after a program modifies 
environ[0], environ[1], etc.  See POSIX 8.1 
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_01>. 
  So, although a POSIX-conforming program can do the above, it can't use getenv 
etc. afterwards.

In contrast the putenv-test.c program I sent earlier 
<http://bugs.gnu.org/19874#68> doesn't modify environ[0], environ[1], etc., so 
it can rely upon getenv etc.

Emacs's problem on FreeBSD occurred because Gnulib's workaround for FreeBSD 
putenv's incompatibility with GNU putenv ran afoul of the POSIX 8.1 restriction. 
  My recent patch worked around the workaround, by telling Emacs to not use 
Gnulib's workaround.  So fixing the FreeBSD bug exemplified by putenv-test.c 
isn't needed to get Emacs to work; still, it's a bug that may bite other programs.