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

[Wolfgang Jenkner]

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