On Wed, Jan 31, 2018 at 05:52:35AM +0100, Theo Buehler wrote: > On Thu, Jan 25, 2018 at 09:35:33PM -0600, Scott Cheloha wrote: > > Hi, > > > > This increases the range for sleep(1) from 100 million seconds up to > > 9223372036854775807. > > > > POSIX.1-2001 added a stipulation (which POSIX.1-2008 retains) that sleep(1) > > support inputs of at least 2147483647 seconds. This patch fulfills that > > requirement and brings us into alignment with POSIX.1-2008, which we already > > claim anyway. > > > > FreeBSD supports up to INT_MAX and no further. GNU sleep keeps seconds > > in a double, so they too ought to support at least this minimum... but > > they do something weird that I haven't quite figured out yet, so I'm > > actually not sure what they support. > > > > But anyway I don't see a reason to cap user input (as FreeBSD does) at the > > positive 32-bit limit when we already carefully parse up to the limit of > > time_t and check for overflow. If the end user wants to sleep that long, > > we can just let them. I have a subsequent patch that tells the user that > > their input is too large in the event of overflow. Currently we just exit > > with EINVAL and say nothing, which is both unusual and unhelpful. > > > > Using a loop to extend the input range of the utility seems a bit unclean, > > but this case alone certainly doesn't warrant extending the input range for > > nanosleep(2). > > > > I'm not sure whether the larger range is actually an extension to the > > standard, and if so whether we need to mention it in the manpage, but > > I've included a diff here anyway just in case. If you have ideas about > > the wording I'd love to hear them. > > > > Thoughts? ok? > > The diff for sleep.c is ok. > > For the manpage part, I have no strong opinion, but I'm not so sure this > is needed/useful. That sleeping for fractions of a second isn't portable > definitely has practical relevance, sleeping longer than 68 years not so > much. I'll leave this for jmc to decide. >
i tend to agree that it's not worth documenting, unless you have a concrete reason to do so. jmc > > > > -- > > Scott Cheloha > > > > Index: bin/sleep/sleep.1 > > =================================================================== > > RCS file: /cvs/src/bin/sleep/sleep.1,v > > retrieving revision 1.22 > > diff -u -p -r1.22 sleep.1 > > --- bin/sleep/sleep.1 16 Aug 2016 18:51:25 -0000 1.22 > > +++ bin/sleep/sleep.1 26 Jan 2018 03:22:08 -0000 > > @@ -108,8 +108,10 @@ utility is compliant with the > > .St -p1003.1-2008 > > specification. > > .Pp > > -The handling of fractional arguments is provided as an extension to that > > -specification. > > +The handling of fractional arguments and the support for values of > > +.Ar seconds > > +greater than 2147483647 > > +are extensions to that specification. > > .Sh HISTORY > > A > > .Nm > > Index: bin/sleep/sleep.c > > =================================================================== > > RCS file: /cvs/src/bin/sleep/sleep.c,v > > retrieving revision 1.24 > > diff -u -p -r1.24 sleep.c > > --- bin/sleep/sleep.c 11 Oct 2015 20:17:49 -0000 1.24 > > +++ bin/sleep/sleep.c 26 Jan 2018 03:22:08 -0000 > > @@ -102,12 +102,24 @@ main(int argc, char *argv[]) > > } > > } > > > > - rqtp.tv_sec = secs; > > - rqtp.tv_nsec = nsecs; > > - > > - if ((secs > 0) || (nsecs > 0)) > > + while (secs > 0 || nsecs > 0) { > > + /* > > + * nanosleep(2) supports a maximum of 100 million > > + * seconds, so we break the nap up into multiple > > + * calls if we have more than that. > > + */ > > + if (secs > 100000000) { > > + rqtp.tv_sec = 100000000; > > + rqtp.tv_nsec = 0; > > + } else { > > + rqtp.tv_sec = secs; > > + rqtp.tv_nsec = nsecs; > > + } > > if (nanosleep(&rqtp, NULL)) > > err(1, NULL); > > + secs -= rqtp.tv_sec; > > + nsecs -= rqtp.tv_nsec; > > + } > > return (0); > > } > > > >