5 ms·
Also beware storing milliseconds in 32-bit quantities (as if you'd ever! but it happens). GetTickCount is the poster child for this class of bugs: http://en.wi
by sehugg 15y ago
Also beware storing milliseconds in 32-bit quantities (as if you'd ever! but it happens).
GetTickCount is the poster child for this class of bugs: http://en.wikipedia.org/wiki/GetTickCount http://en.wikipedia.org/wiki/GetTickCount
In fact some versions of Windows CE intentionally set this value to (0xffffffff - 10 minutes) before bootup so that bugs were more likely to come out in testing, rather than showing up 42 days after bootup.
Also, don't store time intervals as floating point, especially if you're working on a missile system: http://apps.ycombinator.com/item?id=1667060 http://apps.ycombinator.com/item?id=1667060
- CamperBob 15y agoYou can store milliseconds in 32-bit quantities all you want, if you remember the One True Axiom of Time: never compare tick counts, always subtract and compare to the difference you were looking for. If you do it that way, you can't screw it up, at least in C.
- deleted 15y ago[deleted]
- cbr 15y agoReally? What if it wraps around? ts1=MAX_INT-40, ts2=20, ts2-ts1 < 0. Or does that actually work out correctly with signed integers in C?
- CamperBob 15y agoIt works regardless of signed/unsigned type, because signed ints still wrap at UINT_MAX (and not at INT_MAX).
- wnoise 15y agoTechnically, overflow of signed integers invokes undefined behavior (or possibly implementation defined. In my copy of a draft standard overflow is given as an example of undefined behavior, but 6.3.1.3 say implementation defined). In practice, it's the same bit values as unsigned integers, which does the right thing in this case.