[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs current-time-string core dump on 64-bit hosts
From: |
Eli Zaretskii |
Subject: |
Re: Emacs current-time-string core dump on 64-bit hosts |
Date: |
Fri, 17 Mar 2006 14:16:27 +0200 |
> From: Paul Eggert <eggert@CS.UCLA.EDU>
> Gcc: nnfolder+archive:outgo
> Date: Thu, 16 Mar 2006 21:58:09 -0800
>
> 2006-03-16 Paul Eggert <eggert@cs.ucla.edu>
>
> Do not use ctime, since it has undefined behavior with
> out-of-range time stamps. This fixes a bug where
> (current-time-string '(2814749767106 0)) would make Emacs dump
> core on 64-bit Solaris 8; the fix is to remove all uses of ctime
> from the Emacs source code.
Personally, 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?
> (Fdecode_time): Cast tm_year to EMACS_INT, to avoid overflow when
> int is narrow than EMACS_INT.
Can it happen that an int is narrower than EMACS_INT? I thought it
was impossible, but perhaps I'm mistaken.
If this cannot happen, let's not clutter the code with unnecessary
kludges.
> * lib-src/ntlib.c (sys_ctime): Remove, since Emacs never calls
> ctime any more.
> * lib-src/ntlib.h (ctime): Likewise.
> * src/w32.c (sys_ctime): Likewise.
> * src/s/ms-w32.h (ctime): Likewise.
I wouldn't remove these: the functions are almost trivial wrappers
around the library version, and someone could try using ctime in the
future (in a different context), in which case they will hit the
Windows library bug again.