svn commit: r300384 - head/sys/compat/ndis

[Pedro Giffuni]

> Il giorno 21/mag/2016, alle ore 21:15, Bruce Evans <brde at optusnet.com.au> ha scritto:
> 
> On Sun, 22 May 2016, Pedro F. Giffuni wrote:
> 
>> Log:
>> ndis(4):  adjustments for our random() specific implementation.
>> 
>> - Revert r300377: The implementation claims to return a value
>>   within the range. [1]
>> - Adjust the value for the case of a zero seed, whihc according
>>   to standards should be equivalent to a seed of value 1.
> 
> This was already correct.  Standards don't say that a seed of 0 for
> srand() means the same as a seed of 1 passed to srand().  They say
> that if srand() is not called, then the sequence shall be the same
> as if it had been called with a seed of 1.  This is already
> implemented by using an internal initial value of the seed that is
> the result of srand(1).
> 

OK. I misunderstood the standard. I will revert the if seed thing.
(Tomorrow).


> The commit gives the following bugs:
> - srand() is less random.  srand(0) now gives the same sequence as
>  srand(0)
> - srand(0) is not binary compatible.
> 
> My previous mail pointed out the version in libc is the kernel version
> with some bugs fixed.  It also has some regressions.  In the libc
> version, srand(seed) sets the internal seed almost directly (it just
> adds 1 for technical reasons).  The kernel version advances the seed
> through 50 iterations of random().  This doesn't really increase
> randomness but it makes the linearity relation in the LCG less obvious.
> 

Merging both is out of scope from what I expected to be a much simpler
cleanup for ndis(4).

I would have liked to replace completely random() with something like
Mersenne Twister + unpredictable seed but that is basically a waste of
time: developers seem sufficiently happy with random() and when not
arc4random() can be used. :-/

Thanks for all this feedback.

Pedro.
>