[Bug libc/15615] Poor quality output from rand_r

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15615

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
On Tue, Jun 25, 2013 at 06:58:21AM +0000, neleai at seznam dot cz wrote:
> I am still not convinced that changing implementation is improvement as
> everybody which cares about quality uses random_r. 

It's definitely an improvement in quality. This has been measured
extensively, and much of the improvement is not just empirical but
provable mathematically (uniformity).

The only question in my mind is whether there are applications which
depend on the existing low quality, e.g. to keep generating the same
outputs based on the same seeds.

> I would accept an warning that rand_r is weak and one should use
> random_r.

random_r is not portable. I agree rand_r is low quality, but the
motivation for using it is that it's the only portable prng that's
thread-safe, restartable, and has thread-local state (so that its
output is not affected by simultaneous use in other threads). I would
not promote its use (an equally-trivial 64- or 128-bit-state prng is
just as small and easy to write and can easily be dropped into any
application) but I can think of two potential reasons for wanting a
rand_r with the best quality it can provide within its interface
limitations:

1. Applications currently using rand_r that have not been tested
heavily, at least not on glibc.

2. Naive "fixing" of libraries that use rand to use rand_r by
programmers not aware of the quality issues with rand_r.

-- 
You are receiving this mail because:
You are on the CC list for the bug.