Re: Emacs current-time-string core dump on 64-bit hosts

[Paul Eggert]

Eli Zaretskii <eliz@gnu.org> 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.