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: Fri, 24 Mar 2006 13:00:15 -0800 Message-ID: <87bqvv1rts.fsf@penguin.cs.ucla.edu> References: <87k6arnqsx.fsf@penguin.cs.ucla.edu> <87fyle6luu.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 1143271670 15606 80.91.229.2 (25 Mar 2006 07:27:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 25 Mar 2006 07:27:50 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 25 08:27:48 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 1FN3BW-0006QD-Oc for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Mar 2006 08:27:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FN3BV-0003ph-WC for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Mar 2006 02:27:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FMtOX-0006sW-Mq for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2006 16:00:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FMtOW-0006sE-VU for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2006 16:00:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FMtOW-0006sB-N4 for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2006 16:00:28 -0500 Original-Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FMtPG-0003Z1-2k; Fri, 24 Mar 2006 16:01:14 -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 k2OL0F814498; Fri, 24 Mar 2006 13:00:16 -0800 (PST) Original-Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1FMtOJ-0004jE-Hd; Fri, 24 Mar 2006 13:00:15 -0800 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Mon, 20 Mar 2006 20:00:50 -0500") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-Mailman-Approved-At: Sat, 25 Mar 2006 02:27:33 -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:14987 Archived-At: Richard Stallman writes: > > I think it is possible, even trivial, to fix ctime. The largest year > > value that can be represented in a 64-bit time-value is around 1 > > trillion, and that will fit in 12 digits. Isn't this trivial to fix? > > No, because ctime is implemented in terms of localtime, localtime is > defined to use an 'int' to represent the year, and 'int' is only 32 > bits on most hosts. > > I do not follow you. If conversion to `int' truncates the year, that > can cause incorrect results, but it can't cause the results to be any > further out of range. The year in `ctime' will still fit in 12 digits. True. I had interpreted "fix ctime" to mean "ctime must always return a string that contains the correct year, month, day, etc., assuming the Gregorian calendar with no leap seconds". But by "fix ctime" you merely meant "ctime must never crash". In that case, yes, a fix is trivial, and the GNU C library's ctime implementation already does that: its ctime always returns NULL (setting errno) with out-of-range inputs.