From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 32902@debbugs.gnu.org
Subject: bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps
Date: Sun, 7 Oct 2018 22:18:12 -0700 [thread overview]
Message-ID: <cb076958-3b90-7e4c-89f6-60fee2999f4b@cs.ucla.edu> (raw)
In-Reply-To: <83va6dyx69.fsf@gnu.org>
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.
next prev parent reply other threads:[~2018-10-08 5:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 1:00 bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps Paul Eggert
2018-10-02 3:04 ` Eli Zaretskii
2018-10-03 18:45 ` Paul Eggert
2018-10-04 16:08 ` Eli Zaretskii
2018-10-07 6:32 ` Paul Eggert
2018-10-07 17:55 ` Eli Zaretskii
2018-10-07 20:05 ` Paul Eggert
2018-10-08 2:44 ` Eli Zaretskii
2018-10-08 5:18 ` Paul Eggert [this message]
2018-10-09 15:09 ` Eli Zaretskii
[not found] ` <3f0bcf06-83f2-a0e9-c9ab-b06d65417afe@cs.ucla.edu>
2018-10-10 3:49 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb076958-3b90-7e4c-89f6-60fee2999f4b@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=32902@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.