[ENet-discuss] UDPX_TIME_OVERFLOW 86400000

[Jim Purbrick]

Fine. I should be OK then.

Is there any reason why you can't just use the full range of an unsigned int
though?

#define TIME_LESS(a, b) ((long)((a)-(b)) < 0)
#define TIME_LESS_EQUAL(a, b) ((long)((a)-(b)) <= 0)
#define TIME_GREATER(a, b) ((long)((a)-(b)) > 0)
#define TIME_GREATER_EQUAL(a, b) ((long)((a)-(b)) >= 0)

> -----Original Message-----
> From: Lee Salzman [mailto:lsalzman at telerama.com]
> Sent: 09 February 2004 19:34
> To: Discussion of the ENet library
> Subject: Re: [ENet-discuss] UDPX_TIME_OVERFLOW 86400000
> 
> 
> Well, it's tricky. Take for example:
> 
> #define ENET_TIME_LESS(a, b) ((a) - (b) >= ENET_TIME_OVERFLOW)
> 
> With respect to this, I have to allow for a legitimate positive
> difference to exist between "a" and "b", i.e. where "a" 
> really occurs at
> a greater time than "b". However, nowhere in ENet are any two values
> compared where the difference between "a" and "b" is going to 
> be greater 
> than a day (just as some nice reasonable value, thus a day 
> makes sense),
> which happens to be 86,400,000 milliseconds. If there is a greater
> difference than that, then a time overflow happened, in which case "a"
> is really less than "b". This means ENet will never have year 3000 or
> year 5 billion problems (if it is still around then), as it handily 
> escapes rollover. :)
> 
> The overflow handling appeals to reasonable difference in time used
> within ENet, not to any specific limit as to what can be stored in the
> integer (so long as it is unsigned, anyway). Make sense?
> 
> Lee
> 
> On Mon, Feb 09, 2004 at 05:00:56PM -0000, Jim Purbrick wrote:
> > What's the reasoning behind this value? I would have 
> thought it would be
> > ~4294967295 for a unsigned int wrapping clock.
> > 
> > The reason I ask is that I need to rewrite the clock using 
> our WallClock
> > time, which returns a double in seconds. In order to 
> convert it to an ENet
> > style millisecond clock I multiply by 1000, fmod with
> > std::numeric_limits<int>::max() and then truncate to an integer.
> > 
> > Because I'm using integers, rather than unsigned ints, I 
> expected to have to
> > change the overflow value to ~2147483647, but the existing 
> value of 86400000
> > confused me.
> > 
>