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

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@CS.UCLA.EDU>
> Date: Fri, 17 Mar 2006 16:44:54 -0800
> 
> > I wouldn't remove these [redefinitions of ctime under Microsoft
> > Windows]: the functions are almost trivial wrappers around the
> > library version, and someone could try using ctime in the future (in
> > a different context),
> 
> But the whole point of the patch is that Emacs should not use ctime,
> for the same reason that Emacs should not use gets.

No, the point is that Emacs shouldn't use ctime _for_arguments_that_
_come_from_an_uncontrolled_source_.  But I still could imagine some
possible valid use in the future where the argument is generated by
code we control.  Having a 4-liner ready for such a situation is a
price I think we could manage to pay.

> Like gets, we should remove all uses of ctime from Emacs, and never
> use it again.

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, I'd look very hard for other solutions.  Others suggested here
to test the argument for validity, for example.

> Emacs utility programs shouldn't crash simply because the clock is set
> to a large value.

No one is arguing that they should.  But IMHO the solution you suggest
is not the best one.  Time calculations are a very complex issue, as
I'm sure you know only too well; having that complex stuff inside
Emacs is a maintenance burden that we should avoid.