Re: [PATCH REVISED] Avoid overflows in kernel/time.c

2007-12-14 Thread H. Peter Anvin
Sam Ravnborg wrote: I understood that bc is unreliable. How about creating a small .c program that does to necessary computation and integrate it in the build process. It should be much cleaner than this approach. You'd have to include an extended-precision library in said C program.

Re: [PATCH REVISED] Avoid overflows in kernel/time.c

2007-12-14 Thread Sam Ravnborg
On Thu, Dec 13, 2007 at 05:13:19PM -0800, H. Peter Anvin wrote: > When the conversion factor between jiffies and milli- or microseconds > is not a single multiply or divide, as for the case of HZ == 300, we > currently do a multiply followed by a divide. The intervening > result, however, is

Re: [PATCH REVISED] Avoid overflows in kernel/time.c

2007-12-14 Thread Sam Ravnborg
On Thu, Dec 13, 2007 at 05:13:19PM -0800, H. Peter Anvin wrote: When the conversion factor between jiffies and milli- or microseconds is not a single multiply or divide, as for the case of HZ == 300, we currently do a multiply followed by a divide. The intervening result, however, is subject

Re: [PATCH REVISED] Avoid overflows in kernel/time.c

2007-12-14 Thread H. Peter Anvin
Sam Ravnborg wrote: I understood that bc is unreliable. How about creating a small .c program that does to necessary computation and integrate it in the build process. It should be much cleaner than this approach. You'd have to include an extended-precision library in said C program.

[PATCH REVISED] Avoid overflows in kernel/time.c

2007-12-13 Thread H. Peter Anvin
When the conversion factor between jiffies and milli- or microseconds is not a single multiply or divide, as for the case of HZ == 300, we currently do a multiply followed by a divide. The intervening result, however, is subject to overflows, especially since the fraction is not simplified (for

[PATCH REVISED] Avoid overflows in kernel/time.c

2007-12-13 Thread H. Peter Anvin
When the conversion factor between jiffies and milli- or microseconds is not a single multiply or divide, as for the case of HZ == 300, we currently do a multiply followed by a divide. The intervening result, however, is subject to overflows, especially since the fraction is not simplified (for