src/lib/libc/stdlib/rand.3, branch release/14.4.0

Remove $FreeBSD$: one-line nroff pattern

2023-08-16T17:55:15Z

Remove /^\.\\"\s*\$FreeBSD\$$\n/

rand(3): Replace implementation with one backed by random(3) algorithm

2020-02-01T20:33:23Z

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

Deprecate sranddev(3) API

2019-12-14T08:28:10Z

It serves no useful purpose and wasn't as popular as its equally meritless cousin, srandomdev(3). Setting aside the problems with rand(3) in general, the problem with this interface is that the seed isn't shared with the caller (other than by attacking the output of the generator, which is trivial, but not a hallmark of pleasant API design). The (arguable) utility of rand(3) or random(3) is as a semi-fast simulation generator which produces consistent results from a given seed. These are mutually at odd. Furthermore, sometimes people got the mistaken impression that a high quality random seed meant a weak generator like rand(3) or random(3) could be used for things like cryptographic key generation. This is absolutely not so. The API was never part of a standard and was not widely used in tree. Existing in-tree uses have all been removed. Possible replacement in out of tree codebases: char buf[3]; time_t t; time(t); strftime(buf, sizeof(buf), "%S", gmtime(&t)); srand(atoi(buf)); Relnotes: yes

rand.3: Match better recommendation language from random.3

2019-04-22T16:26:39Z

Renumber clauses to reduce diffs to other versions

2013-06-13T00:19:30Z

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 number

2013-04-02T23:41:20Z

source sysctl(KERN_ARND) and remove the fallback code. Obtained from: OpenBSD Reviewed by: secteam MFC after: 1 month

Bump dates.

2012-09-04T22:03:16Z

Reminded by: bz@

Add a prominent warning about these functions' unsuitability for

2012-09-04T21:40:53Z

cryptographic purposes, and recommend using arc4random(3) instead.

Missed space.

2010-10-06T09:24:33Z

Submitted by: brueffer MFC after: 1 week

Add cross-references to lrand48(3) and arc4random(3) from rand(3)

2010-10-06T09:05:47Z

and random(3). Submitted by: Valentin Nechayev MFC after: 1 week