src/lib/libc/stdlib/random.3, branch releng/14.4FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F14.42023-08-16T17:55:15ZRemove $FreeBSD$: one-line nroff pattern2023-08-16T17:55:15ZWarner Loshimp@FreeBSD.org2023-08-16T17:55:15Zurn:sha1:b2c76c41be32f904179efed29c0ca04d53f3996c
Remove /^\.\\"\s*\$FreeBSD\$$\n/
rand(3): Replace implementation with one backed by random(3) algorithm2020-02-01T20:33:23ZConrad Meyercem@FreeBSD.org2020-02-01T20:33:23Zurn:sha1:672e12255da9b211d5318889ed9441ffc63c9f30
rand(3)'s standard C API is extremely limiting, but we can do better
than the historical 32-bit state Park-Miller LCG we've shipped since
2001: r73156.
The justification provided at the time for not using random(3) was that
rand_r(3) could not be made to use the same algorithm. That is still
true. However, the irrelevance of rand_r(3) is increasingly obvious.
Since that time, POSIX has marked the interface obsolescent. rand_r(3)
never became part of the standard C library. If not for API
compatibility reasons, I would just remove rand_r(3) entirely.
So, I do not believe it is a problem for rand_r(3) and rand(3) to
diverge.
The 12 ABI is maintained with compatibility definitions, but this
revision does subtly change the API of rand(3). The sequences of
pseudorandom numbers produced in programs built against new versions of
libc will differ from programs built against prior versions of libc.
Reviewed by: kevans, markm
MFC after: no
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D23290
random.3: Some minor improvements to wording/clarity2020-01-20T23:44:10ZConrad Meyercem@FreeBSD.org2020-01-20T23:44:10Zurn:sha1:825a73c36fad8c124870619e4d798c6867424eadrandom.3: Remove obsolete BUGS section2019-04-22T16:29:34ZConrad Meyercem@FreeBSD.org2019-04-22T16:29:34Zurn:sha1:680defa7cefe932be1a4d3f3bf97c6e5d2eb63e3
Relative performance to rand(3) is sort of irrelevant; they do different things
and a user with sensitivity to RNG performance won't use libc random(3) anyway.
The historical note about bad seeding is long obsolete, referring to a 1996 or
earlier version of FreeBSD.
Sponsored by: Dell EMC Isilon
random.3: Clarify confusing summary2019-04-15T18:49:04ZConrad Meyercem@FreeBSD.org2019-04-15T18:49:04Zurn:sha1:1631235aa6084c51978c52785c6c0e9837c0a5ba
random.3 is only "better" in contrast to rand.3. Both are non-cryptographic
pseudo-random number generators. The opening blurbs of each's DESCRIPTION
section does emphasize this, and correctly directs unfamiliar developers to
arc4random(3). However, the summary (".Nd" or Name description) of random.3
conflicted in tone and message with that warning.
Resolve the conflict by clarifying in the Nd section that random(3) is
non-cryptographic and pseudo-random. Elide the "better" qualifier which
implied a comparison but did not provide a specific object to contrast.
Sponsored by: Dell EMC Isilon
Fix typing of srandom() and initstate().2016-07-26T20:11:29ZEd Schoutened@FreeBSD.org2016-07-26T20:11:29Zurn:sha1:8de6c267117c2eb423b1a940601d8e4d525c5f4d
POSIX requires that these functions have an unsigned int for their first
argument; not an unsigned long.
My reasoning is that we can safely change these functions without
breaking the ABI. As far as I know, our supported architectures either
use registers for passing function arguments that are at least as big as
long (e.g., amd64), or int and long are of the same size (e.g., i386).
Reviewed by: ache
Differential Revision: https://reviews.freebsd.org/D6644
Reflect error indication according to POSIX and what those functions2016-06-05T15:46:14ZAndrey A. Chernovache@FreeBSD.org2016-06-05T15:46:14Zurn:sha1:16bf528dc243f86776a443cba84866cfd7d2027e
currently do.
Adjust wording slightly to emphasize that random(3) should not be used for2015-02-25T07:49:15ZColin Percivalcperciva@FreeBSD.org2015-02-25T07:49:15Zurn:sha1:eb51316b50c8cdc4b0397a569e18619778bea5c5
any applications which need unpredictable random numbers, not merely those
which are cryptographic in nature.
If you work for a lottery and you're using random(3) to select the winning
numbers, please let me know.
Renumber clauses to reduce diffs to other versions2013-06-13T00:19:30ZEd Masteemaste@FreeBSD.org2013-06-13T00:19:30Zurn:sha1:580b4d185bc1d20da91429229920ce590309cbf6
NetBSD, OpenBSD, and Android's Bionic number the clauses 1 through 3,
so follow suit to make comparison easier.
Replace access to /dev/random with the kernel pseudo-random number2013-04-02T23:41:20ZXin LIdelphij@FreeBSD.org2013-04-02T23:41:20Zurn:sha1:12a6865090ad2f88c671256c53a8fed4d5424424
source sysctl(KERN_ARND) and remove the fallback code.
Obtained from: OpenBSD
Reviewed by: secteam
MFC after: 1 month