From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wolfgang Jenkner Newsgroups: gmane.emacs.bugs Subject: bug#19874: 25.0.50; encode-time not working as expected Date: Sun, 01 Mar 2015 17:42:22 +0100 Message-ID: <85vbikvewg.fsf@iznogoud.viz> References: <54EE0959.5080901@cs.ucla.edu> <86sidta5ak.fsf@chateau.d.if> <54EED638.8070604@cs.ucla.edu> <85385s94c9.fsf@iznogoud.viz> <54EF5ECD.2030909@cs.ucla.edu> <85mw405whp.fsf@iznogoud.viz> <86a900sbix.fsf@chateau.d.if> <85ioeo5tgf.fsf@iznogoud.viz> <8661aos5ui.fsf@chateau.d.if> <85h9u8rrsb.fsf@iznogoud.viz> <864mq8ar1g.fsf@chateau.d.if> <54F010E7.3040900@cs.ucla.edu> <8561an5k8q.fsf@iznogoud.viz> <54F10399.8010207@cs.ucla.edu> <85lhjim8ig.fsf@iznogoud.viz> <54F21A4E.70707@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425228803 8224 80.91.229.3 (1 Mar 2015 16:53:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Mar 2015 16:53:23 +0000 (UTC) Cc: 19874@debbugs.gnu.org, Ashish SHUKLA To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 01 17:53:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YS77B-0000F4-3Z for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Mar 2015 17:53:13 +0100 Original-Received: from localhost ([::1]:53166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS77A-0005Vm-DO for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Mar 2015 11:53:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS776-0005Tm-MZ for bug-gnu-emacs@gnu.org; Sun, 01 Mar 2015 11:53:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YS770-0003yW-PY for bug-gnu-emacs@gnu.org; Sun, 01 Mar 2015 11:53:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS770-0003yS-Mo for bug-gnu-emacs@gnu.org; Sun, 01 Mar 2015 11:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YS770-0007R3-8d for bug-gnu-emacs@gnu.org; Sun, 01 Mar 2015 11:53:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <86vbj35m3n.fsf@chateau.d.if> Resent-From: Wolfgang Jenkner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Mar 2015 16:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19874 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19874-submit@debbugs.gnu.org id=B19874.142522876328552 (code B ref 19874); Sun, 01 Mar 2015 16:53:02 +0000 Original-Received: (at 19874) by debbugs.gnu.org; 1 Mar 2015 16:52:43 +0000 Original-Received: from localhost ([127.0.0.1]:33490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS76g-0007QR-F1 for submit@debbugs.gnu.org; Sun, 01 Mar 2015 11:52:42 -0500 Original-Received: from b2bfep12.mx.upcmail.net ([62.179.121.57]:38570) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS76d-0007QB-QE for 19874@debbugs.gnu.org; Sun, 01 Mar 2015 11:52:40 -0500 Original-Received: from edge11.upcmail.net ([192.168.13.81]) by b2bfep12.mx.upcmail.net (InterMail vM.8.01.05.11 201-2260-151-128-20120928) with ESMTP id <20150301165233.MTWO14748.b2bfep12-int.chello.at@edge11.upcmail.net> for <19874@debbugs.gnu.org>; Sun, 1 Mar 2015 17:52:33 +0100 Original-Received: from iznogoud.viz ([91.119.117.221]) by edge11.upcmail.net with edge id yGsY1p0094mhD3P0BGsY7u; Sun, 01 Mar 2015 17:52:33 +0100 X-SourceIP: 91.119.117.221 Original-Received: from wolfgang by iznogoud.viz with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YS76W-0000Qb-1e; Sun, 01 Mar 2015 17:52:32 +0100 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (berkeley-unix) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:99935 Archived-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;