G'day Mark.
On 15/09/14 11:02, Mark Goodwin wrote:
On 09/15/2014 07:54 AM, Ken McDonell wrote:
2. (more significantly) Following Mark's investigations of arithmetic
errors ...
Thanks Ken, I didn't push my patch because after reading
tv.c more closely I realized there was a more substantial
audit and patch required, which you've now completed by the
looks of it.
I think so.
...
return val->tv_sec + ((long double)val->tv_usec / (long
double)1000000);
}
^^^ cast isn't needed?, but doesn't hurt.
Yep. I wanted to make it very explicit that the division is being done
in (long double) precision.
> ...
val->tv_usec = (long)((long double)(secs - val->tv_sec) * (long
double)1000000 + 0.5);
Just wondering how come you decided to add the half of one millionth
of a second here, to force rounding up. Doesn't the compiler automatically
round up appropriately, so this is redundant? ...
No, cast to (long) truncates ... check the attached C program.
... I assume the 0.5 doesn't need
an explicit long double cast (or the equivalent L suffix).
I'm sure the compiler will promote here and 0.5 should be _exactly_
representable in all of the floating point precisions. But to be
consistent with my explicit casting above, it _should_ be cast to (long
double) ... thanks, I'll fix it.
x.c
Description: Text Data
|