Nick> Today I have experienced a number of crashes in icq2000beta and Xemacs-21.2.45 Nick> on windows. Finally, I found the cause -- my Win2000 (with SP1) has set the Nick> date to 3 Apr 2043 (first of April joke?). Nick> The test case is (current-time-string '(35273 29735 377000)) Nick> According to debugger in Visual Studio, the error "Access Violation" occured in Nick> the body of `current-time-string' (editfns.c, 1254) when it tries to determine Nick> the length of the string that was returned by `ctime': Nick> ------------------------------------------------------------------------------- Nick> /* ctime is documented as always returning a "\n\0"-terminated Nick> 26-byte American time string, but let's be careful anyways. */ Nick> for (len = 0; the_ctime[len] != '\n' && the_ctime[len] != '\0'; len++) Nick> ; Nick> ------------------------------------------------------------------------------- Nick> The problem is that in this case `lisp_to_time' fails to convert lisp Nick> representation of time to a value of time_t type. `ctime' is called with Nick> pointer to -1 and returns an empty string "". Thus the supposition in comment Nick> does not hold. Nick> I'm not sure how to handle this exceptional situation and it Nick> seems a long way till it really hurts. I'm not sure either. 32 bit systems simply stop working after 2038. Presumably by then we'll all be using 64-bit time_t. Martin

Bob Paddock wrote: Yes, but time_t is signed. -- Glynn Clements <glynn.clements(a)virgin.net&gt;