I finally remembered to remove the .it phk :-). On Wed, 19 Dec 2012, Luigi Rizzo wrote: > On Wed, Dec 19, 2012 at 10:51:48AM +0000, Poul-Henning Kamp wrote: >> ... >> As I said in my previous email: >> >> >> typedef dur_t int64_t; /* signed for bug catching */ >> #define DURSEC ((dur_t)1 << 32) >> #define DURMIN (DURSEC * 60) >> #define DURMSEC (DURSEC / 1000) >> #define DURUSEC (DURSEC / 10000000) >> #define DURNSEC (DURSEC / 10000000000) >> >> (Bikeshed the names at your convenience) >> >> Then you can say >> >> callout_foo(34 * DURSEC) >> callout_foo(2400 * DURMSEC) >> or >> callout_foo(500 * DURNSEC) > > only thing, we must be careful with the parentheses > > For instance, in your macro, DURNSEC evaluates to 0 and so > does any multiple of it. > We should define them as > > #define DURNSEC DURSEC / 10000000000 > ... > > so DURNSEC is still 0 and 500*DURNSEC gives 214 > > I am curious that Bruce did not mention this :) Er, he was careful. DURNSEC gives 4, not 0. This is not very accurate, but probably good enough. Your version without parentheses is not so careful and depends on a magic order of operations and no overflow from this. E.g.: 500*DURNSEC = 500*DURSEC / 1000000000 = 500*((dur_t)1 << 32) / 1000000000 This is very accurate and happens not to overflow. But 5 seconds represented a little strangely in nanoseconds would overflow: 5000000000*DURNSEC = 5000000000*((dur_t)1 << 32) / 1000000000 So would 5 billion times DURSEC, but 5 billion seconds is more unreasobable than 5 billion nanoseconds and the format just can't represent that. > > (btw the typedef is swapped, should be "typedef int64_t dur_t") Didn't notice this. BruceReceived on Wed Dec 19 2012 - 14:44:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC