On Fri, Jun 18, 2021 at 09:29:44AM +0200, Claudio Jeker wrote:
> On Thu, Jun 17, 2021 at 08:41:39PM -0500, Scott Cheloha wrote:
> > On Fri, Jun 11, 2021 at 12:17:02PM -0500, Scott Cheloha wrote:
> > > Hi,
> > >
> > > setitimer(2) has a one hundred million second upper bound for timers.
> > > Any timer interval larger than this is considered invalid and we set
> > > EINVAL.
> > >
> > > There is no longer any reason to use this particular limit. Kclock
> > > timeouts support the full range of a timespec, so we can trivially
> > > increase the upper bound without any practical risk of overflow.
> > >
> > > This patch increases the upper bound to UINT_MAX seconds.
> > >
> > > Why UINT_MAX? UINT_MAX is the largest possible input to alarm(3). We
> > > could then simplify the alarm(3) manpage and the libc alarm.c code in
> > > a subsequent patch. POSIX says alarm(3) "is always successful". Our
> > > implementation can fail. It would be nicer/simpler if ours were free
> > > of failure modes.
> > >
> > > ok?
> >
> > 1 week bump.
> >
> > Updated patch: make the maximum value ("max") static and const.
>
> OK claudio@
>
> I wonder if we need a max at all? I guess there is an upper limit to not
> overflow the time_t when calculating the absolute timeout but that is
> probably close to LLONG_MAX / 2.
Exactly. LLONG_MAX / 2 would be a reasonable maximum value. It's
stupid large, simple, and overflow is theoretically impossible.
However I'd rather stick with UINT_MAX to start because it addresses a
concrete problem: supporting the full input range of alarm(3).
If in the future we come across software in the wild that misbehaves
due to this upper bound we can bump it at that time to address that
particular issue. Until then, UINT_MAX is plenty.
