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

From: Wolfgang Jenkner <[email-masked]>
Date: Sat, 28 Feb 2015 15:10:47 +0100

On Fri, Feb 27 2015, Paul Eggert wrote:

> 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.

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.  And the program modifies env1 after it may have copied
to the new `environment'.

Wolfgang