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, 17 Mar 2006 16:44:54 -0800 Message-ID: <873bhgeg3d.fsf@penguin.cs.ucla.edu> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1142667294 9696 80.91.229.2 (18 Mar 2006 07:34:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Mar 2006 07:34:54 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 18 08:34:51 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 1FKVxU-0003iJ-49 for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Mar 2006 08:34:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FKVxT-0000Em-Dg for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Mar 2006 02:34:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FKPYv-0002q1-77 for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2006 19:44:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FKPYu-0002ph-F9 for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2006 19:44:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FKPYu-0002pe-Cf for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2006 19:44:56 -0500 Original-Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FKPdt-0008Nf-Gj for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2006 19:50:05 -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 k2I0is806898 for ; Fri, 17 Mar 2006 16:44:55 -0800 (PST) Original-Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1FKPYs-0007GC-RC for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2006 16:44:54 -0800 Original-To: bug-gnu-emacs@gnu.org In-Reply-To: (Eli Zaretskii's message of "Fri, 17 Mar 2006 14:16:27 +0200") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-Mailman-Approved-At: Sat, 18 Mar 2006 02:34:41 -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:14964 Archived-At: Eli Zaretskii writes: > I find it preposterous that we need to reinvent library > functions. Isn't there a better (safer) library function, or a > combination thereof, that we could use instead of rolling our own? Not really. The only plausible candidate library function is strftime, but it's not suitable. Emacs itself can't use strftime here, because of locale issues; current-time-string wants the C locale, but strftime uses the LC_TIME locale. fakemail and b2m could potentially use strftime. But strftime is such a pain to use that its code won't be much simpler than just doing it ourselves. Also, strftime is a portability nightmare in its own right. Partly for the latter reason Emacs itself uses its own implementation of strftime -- but Emacs's implementation is not easily available to lib-src programs. All in all it's simpler and more easier to maintain in this case, if we simply roll our own code. (If you don't believe me, try writing it the other way....) > Can it happen that an int is narrower than EMACS_INT? Yes, and that occurs on the platform where Emacs had the core dump (64-bit Solaris sparc). > I wouldn't remove these [redefinitions of ctime under Microsoft > Windows]: the functions are almost trivial wrappers around the > library version, and someone could try using ctime in the future (in > a different context), But the whole point of the patch is that Emacs should not use ctime, for the same reason that Emacs should not use gets. Like gets, if you can't control the input, ctime is inherently subject to buffer overruns. Like gets, we should remove all uses of ctime from Emacs, and never use it again. Come to think of it, we should also remove the ctime wrapper from the Mac port. Andreas Schwab writes: > [In b2m] ctime is only ever been called on the current wall time, if > you set that to some outlandish time stamp you already have enough > problems anyway. It has happened to me. I didn't set the clock to an outlandish time; the clock hardware did it to me. Emacs utility programs shouldn't crash simply because the clock is set to a large value.