From: invalid AT invalid DOT fi (Ilari Liusvaara) Newsgroups: comp.os.msdos.djgpp Subject: Re: uclock limitations Date: Fri, 13 Jul 2001 15:58:08 GMT Organization: - Lines: 37 Message-ID: <3b4f1700.2146696@news.mbnet.fi> References: <3b4dba10 DOT 22636569 AT news DOT mbnet DOT fi> <2593-Fri13Jul2001202516+0300-eliz AT is DOT elta DOT co DOT il> <3B4F3D5B DOT C711C042 AT cyberoptics DOT com> <2427-Fri13Jul2001222318+0300-eliz AT is DOT elta DOT co DOT il> NNTP-Posting-Host: mb-u11ip054.mbnet.fi X-Trace: news.clinet.fi 995126313 18634 194.100.165.213 (14 Jul 2001 15:58:33 GMT) X-Complaints-To: abuse AT clinet DOT fi NNTP-Posting-Date: 14 Jul 2001 15:58:33 GMT X-Newsreader: Forte Free Agent 1.21/32.243 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Fri, 13 Jul 2001 22:23:21 +0300, "Eli Zaretskii" sent some highly redudant bits, which seem to contain the following message: >> From: Eric Rudd >> 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