On 04.07.2013 16:30, Dmitry Morozovsky wrote:
> On Thu, 4 Jul 2013, Andrey Chernov wrote:
>
We already pass that moment in the past, changing old&bad formula with
new one which cause the same effect: non-repeating sequence in the very
global scope. We already agree that repeating de
On Thu, 4 Jul 2013, Andrey Chernov wrote:
> >> We already pass that moment in the past, changing old&bad formula with
> >> new one which cause the same effect: non-repeating sequence in the very
> >> global scope. We already agree that repeating depends on something like
> >> OS release numbers. I
On 04.07.2013 11:01, Bruce Evans wrote:
>> We already pass that moment in the past, changing old&bad formula with
>> new one which cause the same effect: non-repeating sequence in the very
>> global scope. We already agree that repeating depends on something like
>> OS release numbers. I can't find
On Thu, 4 Jul 2013, Andrey Chernov wrote:
On 04.07.2013 6:47, Bruce Evans wrote:
Er, I think it is too dangerous to change either RAND_MAX or the offset
without more preparation:
- increasing the range returned (and increasing RAND_MAX to match) would
obviously be binary-incompatible. Old bi
On 04.07.2013 6:47, Bruce Evans wrote:
> Er, I think it is too dangerous to change either RAND_MAX or the offset
> without more preparation:
> - increasing the range returned (and increasing RAND_MAX to match) would
> obviously be binary-incompatible. Old binaries may have the old RAND_MAX
> b
On Wed, 3 Jul 2013, Andrey A. Chernov wrote:
Log:
1) POSIX requires rand(3) return values to be in the [0, RAND_MAX] range,
but ACM formula we use have internal state (and return value) in the
[1, 0x7ffe] range, so our RAND_MAX (0x7fff) is never reached
because it is off by one, zero
Author: ache
Date: Wed Jul 3 21:21:54 2013
New Revision: 252608
URL: http://svnweb.freebsd.org/changeset/base/252608
Log:
1) POSIX requires rand(3) return values to be in the [0, RAND_MAX] range,
but ACM formula we use have internal state (and return value) in the
[1, 0x7ffe] range, so
