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

[Paul Eggert]

Eli Zaretskii <eliz@gnu.org> writes:

> If there's a safer library function, I'd agree.  (There is one for
> gets.)  But if the alternative is to spill the guts of ctime into
> Emacs,

We're talking about 20 obvious lines of code here!  It's not that hard
to maintain.

Let's put this into a bit of perspective here.  Emacs already
maintains its own copy of strftime (about 1500 lines of
somewhat-tricky code), for similar portability reasons.  Is it
reasonable to worry about maintaining ctime when we're not worried
about strftime?


> Others suggested here to test the argument for validity, for
> example.

As I explained on bug-gnu-emacs just now, that particular suggestion
has problems as well.  It won't work as well as the code already
proposed.


> Time calculations are a very complex issue, as I'm sure you know
> only too well;

Sure, but this particular code isn't complex.  It's quite simple and
reliable.  Ugly perhaps, but simple.


> I still could imagine some possible valid use in the future where
> the [ctime] argument is generated by code we control.

I doubt that, but if such a thing ever occurs, we can easily resurrect
the wrapper from CVS.

In the meantime our best bet by far is to tell people this simple rule:

  Don't use ctime.

Such a rule is much easier to remember than this one:

  Don't use ctime unless you have sufficient control over its argument
  time stamps to know that they won't generate more than 26 bytes when
  one naively applies the algorithm on page 341 of the 1999 edition of
  the C Standard.