From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Setting TZ in set_time_zone_rule Date: Fri, 30 Nov 2012 12:47:14 -0800 Message-ID: <50B91B52.5060105@cs.ucla.edu> References: <83624pwq8z.fsf@gnu.org> <50B67266.1000509@cs.ucla.edu> <50B6B886.9020309@cs.ucla.edu> <83zk21ul87.fsf@gnu.org> <50B7D60C.7070306@cs.ucla.edu> <83d2yvv4o0.fsf@gnu.org> <837gp3v26f.fsf@gnu.org> <50B8F96B.80803@cs.ucla.edu> <83sj7qudmw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354308456 3351 80.91.229.3 (30 Nov 2012 20:47:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2012 20:47:36 +0000 (UTC) Cc: schwab@linux-m68k.org, fabrice.popineau@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 30 21:47:47 2012 Return-path: Envelope-to: ged-emacs-devel@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 1TeXUr-0000Ux-I1 for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2012 21:47:41 +0100 Original-Received: from localhost ([::1]:41249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TeXUg-0003fO-5o for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2012 15:47:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TeXUd-0003fG-Pe for emacs-devel@gnu.org; Fri, 30 Nov 2012 15:47:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TeXUc-0001QH-OP for emacs-devel@gnu.org; Fri, 30 Nov 2012 15:47:27 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:59692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TeXUa-0001Pd-Ff; Fri, 30 Nov 2012 15:47:24 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E0A0F39E8105; Fri, 30 Nov 2012 12:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4fTbo8DlhDJ; Fri, 30 Nov 2012 12:47:15 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 7301C39E8008; Fri, 30 Nov 2012 12:47:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <83sj7qudmw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155153 Archived-At: On 11/30/12 10:52, Eli Zaretskii wrote: >> set_time_zone_rule (0) needs to unset TZ. > > Do we ever call it that way? Yes, if TZ is unset in the environment. >>>>> Also, is unsetenv("TZ") the same as putenv("TZ=") ? >>> Yes. >> >> Doesn't the former unset TZ, and the latter set TZ to the empty string? > > The implementation I saw unset TZ in both cases. Which implementation is that? It does not conform to POSIX. At any rate, we can't rely on that behavior. I just thought of another problem: setenv has a memory leak, by design: it leaks the memory holding the previous value of the environment variable. So I guess we should use putenv after all. We can use the gnulib putenv module for hosts that lack putenv. We'll also need unsetenv (but not setenv). I'll look into drafting a patch along these lines this weekend. The code is a bit of a mess in this area, unfortunately. Among other things, the current uses of setenv and putenv assume that they always succeed, but they can fail just as malloc can fail, due to lack of memory.