Re: [ECOS] clock() problem?

[Hugo Tyson <hmt at redhat dot com>]

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