There was an overflow problem in the part that tries to prepare a 64-bit
value to put into the 32-bit halves of `FILETIME`. I've pushed a
repair.
Thanks for the report and help!
At Fri, 19 Feb 2016 18:06:55 -0500, Jon Zeppieri wrote:
> Er, no. Disregard that. That'll teach me to talk about the
:* viernes, 19 de febrero de 2016 23:31
> *To:* Jos Koot
> *Cc:* Racket Users
> *Subject:* Re: [racket-users] second->date
>
> I'm not especially familiar with the code in question, but it looks to me
> like some time-handling code in fun.c assumes 32-bit values. I'm referring
>
tly) 35680317?
Jos
_
From: Jon Zeppieri [mailto:zeppi...@gmail.com]
Sent: viernes, 19 de febrero de 2016 23:31
To: Jos Koot
Cc: Racket Users
Subject: Re: [racket-users] second->date
I'm not especially familiar with the code in question, but it looks to me
like some time-handling code
Er, no. Disregard that. That'll teach me to talk about the Windows API when
I know nothing about it. Apparently, the FILETIME type is divided into two
32-bit values.
At any rate, there is a bug, but I don't know where it is.
-Jon
On Fri, Feb 19, 2016 at 5:31 PM, Jon Zeppieri
I'm not especially familiar with the code in question, but it looks to me
like some time-handling code in fun.c assumes 32-bit values. I'm referring
to this: [
https://github.com/racket/racket/blob/50db01bf2c7c57fd5c7c662307d517ce2c29c279/racket/src/racket/src/fun.c#L9981
].
On a 64-bit system,
The following surprises me:
> (seconds->date (sub1 (expt 2 40)))
seconds->date: integer is out-of-range
integer: 1099511627775
Nevertheless I can go further on in time:
> (seconds->date (sub1 (expt 2 50)))
#(struct:date*
40
5
11
23
9
22520
1
266
#t
7200
0
"Romance
6 matches
Mail list logo
