From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24850 invoked by alias); 25 Jun 2013 12:25:53 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 24808 invoked by uid 55); 25 Jun 2013 12:25:47 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug libc/15615] Poor quality output from rand_r Date: Tue, 25 Jun 2013 12:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00206.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15615 --- Comment #6 from Rich Felker --- 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.