Date:	Wed, 11 Aug 1999 15:06:14 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Thiago F.G. Albuquerque" <thiagofga AT ambr DOT com DOT br>
cc:	djgpp AT delorie DOT com
Subject:	Re: uclock() and Integer
In-Reply-To:	<3.0.5.32.19990809232331.007a9bc0@200.252.238.1>
Message-ID:	<Pine.SUN.3.91.990811145631.19078C-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 9 Aug 1999, Thiago F.G. Albuquerque wrote:

> "(...) `printf' cannot print a value of type `uclock_t', even though
> it is an integer value, because it is a 64-bit integer."

That's a lie.  Use the "%Ld" format specifier, and `printf' will print 
uclock_t just fine.

(The docs has been updated for the upcoming v2.03 of DJGPP.)

> However, the first lines of output were:
> 
> 25
> 2317
> 4860
> 7466
> 10050
> 12645
> 15236
> -47579
> -45450
> -42852
> -40260
> -37660
> -35064
> -32469
> -30044
> -27873
> -25200
> -22602
> 
> Why is it printing negative values?

Let me guess: you are running this on Windows 9X, right?

If so, then the problem is that `uclock' reprograms the system timer when 
you call it the first time, and Windows does not update the actual timer 
device with the new mode until the next timer tick.  So, during the first 
timer tick interval after the first call to `uclock', the timer still 
works in its original mode, before it was reprogrammed, and confuses the 
computations inside `uclock'.

In DJGPP v2.03, `uclock' was changed to wait until the timer ticks when 
it is called for the first time.  This solves the problem.  As a 
work-around, you can do the same in your code, like this:

   int otics;
   uclock ();
   _farsetsel(_dos_ds);
   otics = _farnspeekl(0x46c);
   do {
     errno = 0;
     __dpmi_yield();   /* will set errno to ENOSYS on plain DOS */
   } while (errno == 0 && _farnspeekl(0x46c) == otics);

   uclock ();

- Raw text -