GNU bug report logs - #9000
patch for higher-resolution time stamps

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Tue, 5 Jul 2011 06:42:02 UTC

Severity: normal

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: 9000 <at> debbugs.gnu.org
Subject: Re: bug#9000: patch for higher-resolution time stamps
Date: Sat, 23 Jun 2012 13:48:41 +0300
> Date: Sat, 23 Jun 2012 11:39:40 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 9000 <at> debbugs.gnu.org
> 
> > Date: Fri, 22 Jun 2012 14:21:50 -0700
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > CC: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > No further comment and the patch seems ripe
> > so I installed it into the trunk as bzr 108687
> > and am marking this bug as done.  I'll CC: this
> > to Eli as it affects the Microsoft ports.
> 
> This badly broke the MS-Windows build.  I'm working on fixing it.

I think I fixed this in revision 108698, MS-Windows users please see
if there are any leftovers.  In particular, any feature that uses
system time or file time or 'select' (i.e. subprocesses) is suspect.
I only did some minimal testing.

Paul, please note that I needed changes in 3 gnulib headers:
utimens.h, timespec.h, and stat-time.h.  The change is to include
sys/time.h, because that's where the Windows build defines
'struct timespec' (time.h cannot be used for that).  I hope you can
make these changes in upstream gnulib.

I'm OK with any other solution to this conundrum, which will be
compatible with the following conditions:

 . do not assume that 'struct timespec' is defined on time.h, or on
   any other MS-Windows system header
 . do not use gnulib's time.h (as that requires Sed to edit time.in.h)

It is OK to add headers to Emacs's nt/inc/ directory in order to solve
this, provided that they do not shadow system headers (since MSVC does
not have include_next or its equivalent).

Finally, I see compiler warnings due to the changes in revno 108687:

  dispnew.c: In function `Fsleep_for':
  dispnew.c:5960: warning: comparison is always true due to limited range of data type
  dispnew.c: In function `sit_for':
  dispnew.c:6008: warning: comparison is always true due to limited range of data type

  keyboard.c: In function `kbd_buffer_get_event':
  keyboard.c:3861: warning: comparison is always true due to limited range of data type

  process.c: In function `Faccept_process_output':
  process.c:3999: warning: comparison is always true due to limited range of data type

They all come from snippets such as this one:

    min (EMACS_SECS (t), INTMAX_MAX)

I think any host with a signed 32-bit time_t will see this warning.
Can this annoyance be fixed, please?





This bug report was last modified 12 years and 338 days ago.

Previous Next


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