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 ...

Merge ^/head r356931 through r357118.

random.3: Some minor improvements to wording/clarity

MFHead @347527

Sponsored by: The FreeBSD Foundation

random.3: Remove obsolete BUGS section

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.

random.3: Remove obsolete BUGS section

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

show more ...

random.3: Clarify confusing summary

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 do

random.3: Clarify confusing summary

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

show more ...

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 ...

Merge ^/head r356931 through r357118.

random.3: Some minor improvements to wording/clarity

MFHead @347527

Sponsored by: The FreeBSD Foundation

random.3: Remove obsolete BUGS section

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.

random.3: Remove obsolete BUGS section

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

show more ...

random.3: Clarify confusing summary

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 do

random.3: Clarify confusing summary

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

show more ...

Merge ^/head r303250 through r304235.

Fix typing of srandom() and initstate().

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 fun

Fix typing of srandom() and initstate().

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

show more ...

Reflect error indication according to POSIX and what those functions
currently do.

Merge sync of head

MFH: r278968-r280640

Sponsored by: The FreeBSD Foundation

Merge from head

Merge r278538 through r279514.