Re: Possible off-by-one bug in usr.sbin/rad/engine.c

Coming from a C/C++ background, I would assume, that a range from
200 to 600 comprises numbers would start at 200 and reach as far
as 599. This would be in sync with all STL functions for iterating
through collections or for extracting ranges.

As long as you need two random numbers to craft seconds and
microseconds values, it will be anything but easy to create
a uniform distribution going from 200.0000000 all the way up
to and including 600.000000. As others have already pointed
out, your initially proposed fix certainly does not achieve this.

> Gesendet: Sonntag, 01. Januar 2023 um 15:33 Uhr
> Von: "Alejandro Colomar" <alx.manpages@gmail.com>
> An: "Florian Obser" <florian@openbsd.org>, "Ingo Schwarze" <schwarze@usta.de>
> Cc: misc@openbsd.org
> Betreff: Re: Possible off-by-one bug in usr.sbin/rad/engine.c
>
>
>
> On 1/1/23 14:48, Alejandro Colomar wrote:
> > Hello Florian, Ingo,
> >
> > On 1/1/23 08:24, Florian Obser wrote:
> >> On 2022-12-31 23:54 +01, Ingo Schwarze <schwarze@usta.de> wrote:
>
> [...]
>
> >>>
> >>> With your change, the timeout could go up to 600.999999, i.e. almost 601
> >>> seconds.  I don't know the protocol and can't say whether the change
> >>> would matter, but naively, exceeding the MAX_ feels surprising to me.
>
> Oops, I missed this part. That's where it makes sense. :)
>
> >>>
> >>> Really, this doesn't look like a bug to me...
> >>
> >> Unfortunately the OP did not explain why they think this is a bug.
> >
> > Sorry; my bad; I should have explained it.
> >
> > The thing that led me to believe that it was a bug is that variables or
> > constants called *max* (normally) refer to the maximum value allowed in a range,
> > for which there usually is a *min* counterpart (when it's not simply 0).
> >
> > In this case, it seems MAX_* is really the maximum+1.  I don't know what the
> > code is about, so 200 and 600 just look like magic numbers to me, and I don't
> > know if the maximum is 600 or actually 599.
> >
> >>
> >>>
> >>> Yours,
> >>>    Ingo
> >>
> >
> > Cheers,
> > Alex
> >
>
> --
> <http://www.alejandro-colomar.es/>
>