From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hugo Tyson <hmt@redhat.com>
To: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] clock() problem?
Date: Wed, 15 Nov 2000 06:00:00 -0000
Message-id: <wwtwve573nc.fsf@masala.cygnus>
References: <00111508233800.28506@chouston.logikos.com>
X-SW-Source: 2000-11/msg00192.html


Chris Houston <chouston@logikos.com> writes:
> Has anyone else encountered strange behaviour when using the "clock()" 
> function?  When I use it, the result seems to roll over int 16 bits.
> 
> In packages/language/c/libc/time/v1_x_x/src/clock.cxx, in the clock() 
> function, if I change
> 
>     clocks = ((clock_t)curr_clock * resolution.dividend) /
>      (resolution.divisor * (1000000000 / CLOCKS_PER_SEC));  
> 
> to
> 
>       clocks = (clock_t)((curr_clock * resolution.dividend) /
>      (resolution.divisor * (1000000000 / CLOCKS_PER_SEC)));      
> 
> then the function seems to behave correctly.  It seems that in 
> the first case, the multiplication in the numerator gets truncated to 
> 32 bits.

Overflow bites, I guess.  Or maybe a more liberal sprinkling of casts is
needed to make all the maths be 64 bit.

This really needs rewriting to use the C++ clock conversion facility in the
kernel; look for the word "converter" in clock.hxx and also see the
clockcnv.cxx kernel testcase.  Clock converters split

	foo = bar * A / (B * (10^9/CLOCKS_PER_SEC))

into

	foo = bar * P / Q * R / (S * (10^9/CLOCKS_PER_SEC))

where PR==A and QS==B so as to retain accuracy whilst avoiding overflow.

Contributions welcome ;-)

	- Huge