Date: Sun, 22 May 2016 05:43:20 +0300 From: Andrey Chernov <ache@freebsd.org> To: Bruce Evans <brde@optusnet.com.au>, Pedro Giffuni <pfg@freebsd.org> Cc: cem@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r300377 - head/sys/compat/ndis Message-ID: <8bd5428f-6955-72c3-0294-72f7ef936e16@freebsd.org> In-Reply-To: <20160522091455.A1014@besplex.bde.org> References: <201605211752.u4LHqiHQ031457@repo.freebsd.org> <CAG6CVpXjU3tHdar7d=xyr%2BTmffg0NrQu3q7SD=b6%2BjF=yvVr-Q@mail.gmail.com> <a88c14ea-ee78-54de-6142-08a561a49d98@FreeBSD.org> <CAG6CVpV_3%2B%2BWqg2X23=RM942zaDkyL6fxH2YN0TXUqpPjneCOw@mail.gmail.com> <262938a6-50bd-b6f4-24c9-895b837a368e@FreeBSD.org> <20160522091455.A1014@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22.05.2016 3:06, Bruce Evans wrote: > On Sat, 21 May 2016, Pedro Giffuni wrote: > >> On 05/21/16 16:55, Conrad Meyer wrote: >>> On Sat, May 21, 2016 at 1:40 PM, Pedro Giffuni <pfg@freebsd.org> wrote: >>>> >>>> >>>> On 05/21/16 14:05, Conrad Meyer wrote: >>>>> Won't this still return a negative integer in many cases? >>>>> >>>>> random(9) returns u_long, whereas this rand() routine returns 'int'. >>>>> >>>>> Even on architectures where long is the same size as ordinary >>>>> integers, the range of possible results of the 'random() / 2 + 1' >>>>> expression, before implicit cast to signed, is [1, 2^31] (inclusive). >>>> >>>> According to: >>>> sys/libkern/random.c >>>> >>>> The result is uniform on [0, 2^31 - 1]. >>> >>> Ah, I missed that. Sorry! In that case, I'm not sure why this is >>> needed — the result fits in a non-negative 2's complement signed >>> integer. >> >> Actually, I had missed it too. And I also had no idea we were working >> around the zero singularity. >> >> I will revert the change and will do an adjustment for the case where >> we use 0 as a seed (which in MS should be equivalent to 1). > > The libc version has complications related to this. The libkern > version has rotted by not being kept up to date with the libc version. > 4.4BSD-Lite has sort of the reverse bitrot -- in libc, it only has the > bad LCG that copied from an example in the 1990 C standard, while > it has the better LCG copied from 1988 Communications in the ACM in > libkern. > FreeBSD still has the ACM version in libkern, and has a fixed copy > of that in libc, with the bad old version under an ifdef. > > The libc version now adjusts the range from [0, 0x7fffffff] to > 0, 0x7ffffffd] and reduces RAND_MAX by 2 to match. The claimed uniformity > for the larger range is very wrong, since the ACM algorithm can only > produce numbers in the range [1(or is it 0?), 0x7ffffffe] starting from a > seed in the range [1, 0x7ffffffe(or is it 1 higher?)]. There are problems > at both extremities, and it isn't clear if the new or old adjustments to > avoid them preserve uniformity. It is clear that the range was at least > 1 too high, since the ACM algorithm does a modulo by 0x7fffffff. libc version does range adjustment for better uniformity only for rand(3), not for random(3). There is no RAND_MAX constant in the random(3) API. POSIX require that random(3) should stay in [0, 2^31-1].
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8bd5428f-6955-72c3-0294-72f7ef936e16>