From: Mark Slagell <bald_soprano AT geocities DOT nospam DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: rawclock() bug, not just in docs
Date: Tue, 19 Aug 1997 09:41:13 -0500
Organization: the well-basically society
Lines: 38
Message-ID: <33F9B089.3832@geocities.nospam.com>
References: <33F8AAC0 DOT 2114 AT geocities DOT nospam DOT com> <33F8BE1C DOT 19DF AT cornell DOT edu>
NNTP-Posting-Host: dial50.ppp.iastate.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

A. Sinan Unur wrote:

> you seem to be right about this. if the counter at 0x46c resets at
> midnight, you will get erronous results. one workaround might be to do
> the following:
> 
> unsigned long
> rawclock(void)
> {
>   static unsigned long base = 0;
>   unsigned long rv;
>   rv = _farpeekl(_dos_ds, 0x46c);
>   if (base == 0)
>     base = rv;
>   if( rv < base )   /* see if the counter has reset */
>   {
>     rv += ULONG_MAX - base; /* adjust ticks elapsed */
>     base = rv - (ULONG_MAX - base);  /* adjust base */
>   }
> 
>   return rv - base;
> }
> 
> would this be acceptable?
> --
>    Sinan

Yes, that looks to me like a way to fix rawclock().  I'll try something
like it.  Maybe the midnight bug doesn't bother most folks, but I do
most of my programming in the wee hours, when the wee ones are in bed.
<grin>


-- 
"There is no theory.  You have merely to listen.  Fantasy is the law." 
  -- Claude Debussey

Remove the ".nospam" to reply by email.