bug-gnu-emacs
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]