From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: Re: Emacs current-time-string core dump on 64-bit hosts Date: Sat, 25 Mar 2006 21:25:39 -0800 Message-ID: <874q1lu698.fsf@penguin.cs.ucla.edu> References: <87k6arnqsx.fsf@penguin.cs.ucla.edu> <87fyle6luu.fsf@penguin.cs.ucla.edu> <87fyl71sj5.fsf@penguin.cs.ucla.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1143487776 20297 80.91.229.2 (27 Mar 2006 19:29:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2006 19:29:36 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 27 21:29:32 2006 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FNxP7-0006wt-Ni for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Mar 2006 21:29:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FNxP7-0001Mv-7n for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Mar 2006 14:29:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FNNl4-0002cV-7l for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2006 00:25:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FNNkz-0002cI-RJ for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2006 00:25:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FNNkz-0002cF-Ox for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2006 00:25:41 -0500 Original-Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FNNmB-0004qx-7E; Sun, 26 Mar 2006 00:26:55 -0500 Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p1+Sun/8.11.7/UCLACS-5.2) with ESMTP id k2Q5Pd822167; Sat, 25 Mar 2006 21:25:39 -0800 (PST) Original-Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1FNNkx-0002SJ-8C; Sat, 25 Mar 2006 21:25:39 -0800 Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Sat, 25 Mar 2006 11:10:46 +0200") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-Mailman-Approved-At: Sun, 26 Mar 2006 02:50:35 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:14995 Archived-At: Eli Zaretskii writes: > previously current-time-string never threw an error, while now it > will. Hmm, well, it'd be more precise to say something like this: Previously with out-of-range time stamps, current-time-string sometimes dumped core and sometimes had other (somewhat random) behavior. Now it reliably throws an error. I don't think this change in behavior will be a real problem in practice. The only time stamps affected are those before the year -999 or after the year 9999. Users with old programs won't expect such time stamps to work, since historically those time stamps never worked on 32-bit systems. > In particular, invalid values of the optional argument will now > cause incompatible behavior: where previously current-time-string > would pass -1 to ctime, typically causing "(null)" be the result, it > now signals an error. Actually the typical result for -1 was probably more like "Wed Dec 31 23:59:59 1969", adjusted for the time zone. However, strictly speaking this was relying on undefined behavior, and implementations were free to generate "(null)" or any other string they pleased, or to overrun buffers for that matter. (Admittedly I don't know of any that did these awful things.) > Wouldn't it be better to simply produce some telltale string > instead, and not throw an error? float-time, format-time-string, and decode-time all throw an error when the time isn't representable, so there's good precedent for current-time-string doing the same thing. If we were to take the telltale-string route, then we should probably modify float-time etc. to be consistent. I'd rather leave things be, though.