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

Previous Next

Package: emacs;

Reported by: ashish.is <at> lostca.se (Ashish SHUKLA)

Date: Sun, 15 Feb 2015 13:42:01 UTC

Severity: normal

Found in version 25.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #91 received at 19874 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Jenkner <wjenkner <at> inode.at>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19874 <at> debbugs.gnu.org, Ashish SHUKLA <ashish.is <at> lostca.se>
Subject: Re: bug#19874: 25.0.50; encode-time not working as expected
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




This bug report was last modified 5 years and 118 days ago.

Previous Next


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