From: invalid AT invalid DOT fi (Ilari Liusvaara)
Newsgroups: comp.os.msdos.djgpp
Subject: uclock limitations
Date: Thu, 12 Jul 2001 14:55:16 GMT
Organization: -
Lines: 29
Message-ID: <3b4dba10.22636569@news.mbnet.fi>
NNTP-Posting-Host: mb-u08ip045.mbnet.fi
X-Trace: news.clinet.fi 995036124 8351 194.100.164.234 (13 Jul 2001 14:55:24 GMT)
X-Complaints-To: abuse AT clinet DOT fi
NNTP-Posting-Date: 13 Jul 2001 14:55:24 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


From DJGPP Libc manual, function uclock():

>You cannot time across two midnights with this implementation, giving a 
>maximum useful period of 48 hours and an effective limit of 24 hours.


Is this limitation (almost) impossible to work around, it is already
lifted in 2.04, it is in 'volunteers wanted'-stage or is the manual
wrong (misleading)?

I can't correlate what I see in code with manual description. If I
read the source correctly, then if uclock() is called often enough
(i.e. always two calls in 24hour sliding frame when the count is
running), uclock() has practically no limitations of perioid.

I think that if timer routine (DJGPP installs it's own, right?) would
increment midnight counter every midnight (counting how many midnights
have happened while program has been running), uclock() could measure
time almost indefinetly without any loss of time.

I tried some testing: Two tests say it will work and one says it
won't. I might done something very stupid in that one test that didn't
pass. Note that none of these tests weren't the ultimate one: Actually
try to measure e.g. 50 hours with uclock().



Ilari Liusvaara