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

[Paul Eggert <eggert@CS.UCLA.EDU>]

Richard Stallman <rms@gnu.org> 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.