Re: kern/57718: mstohz rounds down, not up, which leads to surprising bugs when it rounds to zero

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR kern/57718; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57718: mstohz rounds down, not up, which leads to surprising bugs when it rounds to zero
Date: Wed, 22 Nov 2023 09:55:36 -0000 (UTC)

 kre%munnari.OZ.AU@localhost (Robert Elz) writes:
 
 > From what I have seen so far, the uses (including indirect ones via other
 > functions and macros) and so far things look to be all over the place.
 > In the following, the assumption is that 0 is never wanted, regardless of
 > what would otherwise happen...
 
 If you round up, you will get 0 when you pass 0.
 
 
 > For some, rounding down looks to be best (for things like polling, it
 > is generally better to poll slightly faster than expected, than slower,
 
 Consistently waiting for "at least" the time (aka rounding up) is
 consistent with the world, where a delay will be extended when e.g.
 your machine is too slow or is occupied with something else. Code
 should always expect that a delay can take longer than expected.
 
 Of course, your input value (not the result of mstohz) could already
 be truncated. So being "slightly" faster than expected (less than the
 resolution of your time value) is an issue too, but often acceptable.