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

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 19874 <at> debbugs.gnu.org, Ashish SHUKLA <ashish.is <at> lostca.se>
Subject: bug#19874: 25.0.50; encode-time not working as expected
Date: Sat, 28 Feb 2015 11:43:10 -0800

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.

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

Previous Next

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