public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15615] Poor quality output from rand_r Date: Tue, 25 Jun 2013 12:25:00 -0000 [thread overview] Message-ID: <bug-15615-131-ATUiYx75PI@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-15615-131@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2013-06-25 12:25 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-06-12 23:39 [Bug libc/15615] New: " bugdal at aerifal dot cx 2013-06-13 8:26 ` [Bug libc/15615] " neleai at seznam dot cz 2013-06-13 8:26 ` [Bug libc/15615] New: " Ondřej Bílka 2013-06-13 12:38 ` [Bug libc/15615] " bugdal at aerifal dot cx 2013-06-14 12:11 ` Ondřej Bílka 2013-06-14 12:11 ` neleai at seznam dot cz 2013-06-14 15:37 ` bugdal at aerifal dot cx 2013-06-25 6:58 ` Ondřej Bílka 2013-06-25 12:25 ` bugdal at aerifal dot cx [this message] 2014-06-13 15:07 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-15615-131-ATUiYx75PI@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).