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

[Paul Eggert]

Eli Zaretskii <eliz@gnu.org> writes:

> 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?

Not really.  The only plausible candidate library function is strftime,
but it's not suitable.

Emacs itself can't use strftime here, because of locale issues;
current-time-string wants the C locale, but strftime uses the LC_TIME
locale.

fakemail and b2m could potentially use strftime.  But strftime is such
a pain to use that its code won't be much simpler than just doing it
ourselves.  Also, strftime is a portability nightmare in its own
right.  Partly for the latter reason Emacs itself uses its own
implementation of strftime -- but Emacs's implementation is not easily
available to lib-src programs.

All in all it's simpler and more easier to maintain in this case, if
we simply roll our own code.  (If you don't believe me, try writing it
the other way....)


> Can it happen that an int is narrower than EMACS_INT?

Yes, and that occurs on the platform where Emacs had the core dump
(64-bit Solaris sparc).


> 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.  Like gets, if you
can't control the input, ctime is inherently subject to buffer
overruns.  Like gets, we should remove all uses of ctime from Emacs,
and never use it again.

Come to think of it, we should also remove the ctime wrapper from the
Mac port.


Andreas Schwab <schwab@suse.de> writes:

> [In b2m] ctime is only ever been called on the current wall time, if
> you set that to some outlandish time stamp you already have enough
> problems anyway.

It has happened to me.  I didn't set the clock to an outlandish time;
the clock hardware did it to me.

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