src/lib/libc/stdlib/random.c, branch releng/13.1

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

2020-02-01T20:33:23+00:00

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): Abstract routines into _r versions on explicit state

2020-01-24T01:39:29+00:00

The existing APIs simply pass the implicit global state to the _r variants.

No functional change.

Note that these routines are not exported from libc and are not intended to be
exported.  If someone wished to export them from libc (which I would
discourage), they should first be modified to match the inconsistent parameter
type / order of the glibc public interfaces of the same names.

I know Ravi will ask, so: the eventual goal of this series is to replace
rand(3) with the implementation from random(3) (D23290).  However, I'd like to
wait a bit longer on that one to see if more feedback emerges.

Reviewed by:	kevans, markm
Differential Revision:	https://reviews.freebsd.org/D23289

random(3): Abstract state into a single context object

2020-01-24T01:32:16+00:00

No functional change.

Reviewed by:	kevans, markm
Differential Revision:	https://reviews.freebsd.org/D23288

General further adoption of SPDX licensing ID tags.

2017-11-20T19:49:47+00:00

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.

Add comment on use of abort() in libc

2016-10-12T13:56:14+00:00

Suggested by:	jonathan (in review D8133)

abort in srandomdev if kern.arandom sysctl fails

2016-10-05T17:03:22+00:00

The sysctl cannot fail. If it does fail on some FreeBSD derivative or
after some future change, just abort() so that the problem will be found
and fixed.

While abort() is not normally suitable for a library, it makes sense
here.

This is akin to r306636 for arc4random.

Reviewed by:	ed
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D8077

Fix typing of srandom() and initstate().

2016-07-26T20:11:29+00:00

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

Micro optimize: C standard guarantees that right shift for unsigned value

2016-05-29T16:39:28+00:00

fills left bits with zero, and we have exact 32bit unsigned value
(uint32_t), so there is no reason to add "& 0x7fffffff" here.

MFC after:      1 week

1) Unifdef USE_WEAK_SEEDING it is too obsolete to support and makes reading

2016-05-29T11:54:09+00:00

harder.

2) ACM paper require seed to be in [1, 2^31-2] range, so use the same range
shifting as already done for rand(3). Also protect srandomdev() + TYPE_0 case
(non default) from negative seeds.

3) Don't check for valid "type" range in setstate(), it is always valid as
calculated. Instead add a check that rear pointer not exceeed end pointer.

MFC after:      1 week

1) POSIX prohibits printing errors to stderr here and require

2016-05-22T06:18:59+00:00

returning NULL:

"Upon successful completion, initstate() and setstate() shall return a
pointer to the previous state array; otherwise, a null pointer shall
be returned.

Although some implementations of random() have written messages to
standard error, such implementations do not conform to POSIX.1-2008."

2) Move error detections earlier to prevent state modifying.

MFC after:      1 week