Mail Archives: djgpp/1999/08/12/00:13:58
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 -