[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19874: 25.0.50; encode-time not working as expected
From: |
Wolfgang Jenkner |
Subject: |
bug#19874: 25.0.50; encode-time not working as expected |
Date: |
Thu, 26 Feb 2015 14:42:30 +0100 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (berkeley-unix) |
On Thu, Feb 26 2015, Paul Eggert wrote:
> Ashish SHUKLA wrote:
>> When I looked into this before filing this bug report, from what I noticed
>> that it's not using libc's `mktime' function, unlike what you seem to
>> indicate. I'm not sure quite why it's doing that when libc provided mktime
>> works just fine
>
> It may work for this example, but 'configure' checks for a number of
> mktime bugs, and perhaps mktime is not working for some other
> examples.
Indeed, on amd64 time_t is a signed 64 bit type but something doesn't
really support that. Adjusting time_t_max (and time_t_min) as if time_t
were a 32 bit type makes the mktime test pass, so that seems to be
a FreeBSD bug.
diff --git a/m4/mktime.m4 b/m4/mktime.m4
index 3f0e1ee..af60ef8 100644
--- a/m4/mktime.m4
+++ b/m4/mktime.m4
@@ -181,7 +181,7 @@ main ()
time_t_max = (! time_t_signed
? (time_t) -1
- : ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
+ : ((((time_t) 1 << (4 * CHAR_BIT - 2)) - 1)
* 2 + 1));
time_t_min = (! time_t_signed
? (time_t) 0
> Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0? You can
> tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.
What has this to do with FreeBSD?
> When 'configure' says 'checking for working mktime', what's the result?
The test fails with exit status 3 (without the work-around above).
Wolfgang
bug#19874: 25.0.50; encode-time not working as expected, Wolfgang Jenkner, 2015/02/26