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

[Wolfgang Jenkner <wjenkner@inode.at>]

On Sat, Feb 28 2015, Paul Eggert wrote:

> Wolfgang Jenkner wrote:
>> No, I think about the parenthetical remark above: It states `copying the
>> environment strings' and not `copying the pointers to the environment
>> strings'.  Normally, in documentation, copying a `string' refers to the
>> object, i.e the region in memory it occupies, not to the pointer
>> designating it.
>
> That interpretation of the rationale is inconsistent with how putenv
> is required to behave.  If one uses putenv to add a string to the
> environment, one can later alter the string (via strcpy, say), and
> this changes the environment; this is quite clear from the normative
> text.  Under the above interpretation, however, getenv could copy the
> string's contents somewhere else, which would mean that modifying the
> putenv-supplied string would not change the environment.

Sure, if putenv is supported it must be compatible with getenv (as the
standard states) and the interpretation of the rationale in this case
implies that getenv can't copy the strings' content, but setenv may,
IIUC (I'm still just wondering if the test program you posted is
conforming).

> If the rationale were intended to discuss copying the strings'
> contents, then its sentence "copying the environment strings into
> a new array and assigning environ to point to it" would be incorrect,
> as one would not assign environ to point to the new array containing
> the strings' contents, but rather one would assign environ[0],
> environ[1], environ[2], etc. to point within the new array. The
> context of that part of the rationale makes it clear that "assign to
> environ" means "environ = SOMETHING", not "environ[0] = SOMETHING".

Yes, I was simply thinking about something like

	q = environ_tmp;
	for (p = environ; *p; p++, q++)
		*q = strdup(*p);
	environ = environ_tmp;