Hi,

Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> writes:

> Special-casing it in the implementation to return 0 was useless.
> Instead, considering 0 as the value after UINT32_MAX has the property
> that it allows implementing the following function without any
> special cases:
>
> uint32_t
> arc4random_range(uint32_t min, uint32_t max)
> {
> 	return arc4random_uniform(max - min + 1) + min;
> }
>
> This works for any values of min and max (as long as min <= max, of
> course), even for (0, UINT32_MAX).
>
> Oh, and the implementation of arc4random_uniform(3) is now 2 lines
> simpler. :)

While I think this is better than the original meaning, the range [n, n)
cannot produce a (N_0) value.  For this reason, I believe the best
behavior for this would be to abort.

Zero is wrong because it's not in [0, 0), which goes also for all values
of [0, 2**32), but not for [0, -1] in the unsigned number space (which
is why I'm giving it more credit than just returning zero), though
specifying that doesn't sit easy with me, since [x, n) and [x, n-1]
aren't necessarily equivalent.

Furthermore, should the need to rely on "return zero for empty range"
behavior arise, an Autoconf test for arc4random_uniform (0) behavior
would be simpler if the test program aborted, as arc4random_uniform (n)
== 0 is quite valid, and easily could happen at configure time.

Should one needs to produce a uniformly distributed value over the full
range of [0, 2**32), they should invoke arc4random ().  Moving the
special case into a wrapper function is similarly trivial to achieve
either of the discussed behaviors.

Of course, changing existing APIs is never easy...  At least aborts are
easy to spot.

Have a great night.
-- 
Arsen Arsenović