lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...

Remove $FreeBSD$: one-line nroff pattern

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

Merge ^/head r357368 through r357388.

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

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 shi

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

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

show more ...

Deprecate sranddev(3) API

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

Deprecate sranddev(3) API

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

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

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

Sponsored by: Dell EMC Isilon

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...

Remove $FreeBSD$: one-line nroff pattern

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

Merge ^/head r357368 through r357388.

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

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 shi

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

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

show more ...

Deprecate sranddev(3) API

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

Deprecate sranddev(3) API

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

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

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

Sponsored by: Dell EMC Isilon

Merge from head

IFC @ r254014

IFC @253398

Merge fresh head.

Renumber clauses to reduce diffs to other versions

NetBSD, OpenBSD, and Android's Bionic number the clauses 1 through 3,
so follow suit to make comparison easier.

sync from head

Replace access to /dev/random with the kernel pseudo-random number
source sysctl(KERN_ARND) and remove the fallback code.

Obtained from: OpenBSD
Reviewed by: secteam
MFC after: 1 month

MFC @ r241285

IFC @ r242684

Sync from head

Bump dates.

Reminded by: bz@