Re: Emacs current-time-string core dump on 64-bit hosts
Paul Eggert <eggert <at> CS.UCLA.EDU>
2006-04-04 04:57:04 GMT
I got a response via private email from Ulrich Leodolter about that
old comment of his in w32.c and ntlib.c. He wrote:
> I cant remember the context, but i think know the reason for this
> time_t t = -1;
> char *str = ctime(&t);
> I verified that str is a null pointer when this code is compiled with
> MS Visual C/C++ 6.0, but it returns a time string on Linux/GNU.
So it appears that my analysis was correct. That is, the problem was
unrelated to whether the working directory was a network drive. The
problem (which is documented by Microsoft) is that, if a time stamp is
negative, ctime returns a null pointer. This null pointer caused the
circa 1995 edition of Emacs to crash, since 1995 Emacs assumed that
ctime always returns a valid pointer.
If a future edition of Emacs uses ctime, it won't be able to assume
that ctime must return a nonnull pointer. Even assuming reliable
implementations like glibc, a ctime-using Emacs would have to check
whether ctime's returned value is null; and to be portable to
less-reliable implementations like Solaris 8, Emacs would have to
check that ctime's argument is in an implementation-dependent range.
And either way, the w32 wrapper would not be needed.
With that in mind I'd like to re-propose the following minor cleanup
patch to the w32 code. It doesn't fix any bugs, since Emacs no longer
uses ctime. But it simplifies the Emacs code (e.g., it means we don't