GNU bug report logs - #32902
Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps

Previous Next

Full log

Message #33 received at 32902 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32902 <at> debbugs.gnu.org
Subject: Re: bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp
 timestamps
Date: Sun, 7 Oct 2018 22:18:12 -0700

Eli Zaretskii wrote:

>> That's only a very partial fix, unfortunately. I looked into the matter briefly,
>> and was dismayed by how much work would be needed for a real fix, even if I
>> fixed only timefns.c.
> 
> Can you point out a couple of such places?

Well, for starters there are multiple instances of "time_t s = t.tv_sec;" where 
T is of time struct timespec, and evidently this assigns a 64-bit quantity to a 
32-bit value on the platform in question. There's lots more code like that.

> The data width difference notwithstanding,
> the values should all fit in 32-bit time_t.

Ah, I didn't know that. In that case, the changes I was thinking of might not be 
needed for timestamps before 2038. (I write "might" because I would rather not 
spend my limited time to think this through.)
> Microsoft made an incompatible change in its runtime libraries
> around Windows Vista, and switched to 64-bit time_t even on 32-bit
> systems.  Since we still try to support older Windows versions, we
> must use that kludge, and we must limit ourselves to 32-bit time_t in
> 32-bit builds.

Here are some possible suggestions:

1. Redefine 'struct timespec' and 'clock_gettime' on 32-bit MinGW so that they 
use 32-bit time_t only. The redefinitions would be visible only within Emacs; 
you wouldn't actually change MinGW.

2. Have Emacs w32*.c detect the width of the MS-Windows API's time_t at runtime, 
and if necessary convert between any 32-bit time_t on the MS-Windows side and 
the 64-bit time_t visible to the rest of the Emacs C code.

3. Build one Emacs executable for 32-bit MS-Windows Vista and later (with 64-bit 
time_t), and another one for 32-bit MS-Windows XP and older (with 32-bit time_t).

Any of these would insulate the rest of Emacs from this glitch. You mentioned a 
fourth possibility that would also serve:

> drop support for older Windows systems.

Microsoft itself has dropped support for the older MS-Windows systems in 
question, and it would be fine if Emacs dropped support too. We routinely drop 
support for obsolete and no-longer-maintained operating system versions like 
RHEL 5 and Irix 6.5.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.