[Top][All Lists]

[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 13:05:58 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Eli Zaretskii wrote:
   timefns.c: In function 'lisp_to_timespec':
   timefns.c:899:21: warning: passing argument 2 of 'mpz_time' from 
incompatible pointer type [-Wincompatible-pointer-types]
      if (mpz_time (*q, &result.tv_sec))
   timefns.c:828:1: note: expected 'time_t * {aka long int *}' but argument is 
of type '__time64_t * {aka long long int *}'
    mpz_time (mpz_t const z, time_t *t)

I fixed it, but please take a look, perhaps there's a better fix for
this situation.

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.

Wouldn't it be much better to remove the "#define _USE_32BIT_TIME_T" from nt/inc/mingw_time.h? That is what's causing the problem that your fix attempted to paper over. A lot of code assumes that a struct timespec (and struct timeval's) tv_sec component is of type time_t, and defining _USE_32BIT_TIME_T violates that assumption; furthermore it means that MinGW Emacs stops working in 2038 (and doesn't work even now for timestamps more than 20 years into the future, something that is pretty routine for me and I imagine for other users).

Whatever backward-compatibility mess that defining _USE_32BIT_TIME_T attempts to work around, really needs to be worked around in a better way.

reply via email to

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