Mail Archives: djgpp/2001/07/14/12:00:15
On Fri, 13 Jul 2001 22:23:21 +0300, "Eli Zaretskii"
<eliz AT is DOT elta DOT co DOT il> sent some highly redudant bits, which seem
to contain the following message:
>> From: Eric Rudd <rudd AT cyberoptics DOT com>
>> Newsgroups: comp.os.msdos.djgpp
>> Date: Fri, 13 Jul 2001 13:26:35 -0500
>>
>> Eli Zaretskii wrote:
>>
>> > The problem is that `uclock' returns a value of the type uclock_t, which is
>> > defined as long long. That's a 64-bit quantity, and since `uclock's
>> > resolution is 840 nanoseconds, the 64-bit type overflows in about 48 hours.
>>
>> I haven't tried using uclock() to time long intervals, but overflow of the
>> 64-bit quantity is not the problem, since 840ns * 2^64 = 1.5E+13 seconds =
>> 50000 years.
>
>Sorry, I should have looked at the sources before talking.
>
>The problem is not overflow, of course, but the fact that `uclock'
>doesn't look at the system date, for performance reasons. So if you
>time a very long interval by calling `uclock' once before and once
>after, you cannot tolerate more than one midnight between these two
>events, because there's no way of knowing how many midnights passed.
So this fall to category: Manual is misleading.
The problem is that manual is not clear. It seems now to say that you
cannot use uclock for longer perioids than 48hours (i.e. that uclock
will break after 48h or so.) I think that manual should be clearer
about that (i.e. explictly say that the limitation doesn't imply if
value is polled often enough.) I have always before read it uclock
will break and will return bogus values after two midnights, NO MATTER
WHAT.
Ilari Liusvaara
- Raw text -