bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps


From: Paul Eggert
Subject: bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps
Date: Sun, 7 Oct 2018 22:18:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]