libc: Purge unneeded cdefs.h

These sys/cdefs.h are not needed. Purge them. They are mostly left-over
from the $FreeBSD$ removal. A few in libc are still required for macros
that cdefs.h defines. Kee

libc: Purge unneeded cdefs.h

These sys/cdefs.h are not needed. Purge them. They are mostly left-over
from the $FreeBSD$ removal. A few in libc are still required for macros
that cdefs.h defines. Keep those.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42385

(cherry picked from commit 559a218c9b257775fb249b67945fe4a05b7a6b9f)

show more ...

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Fix race between first rand(3) calls with _once().

Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized.

Fix race between first rand(3) calls with _once().

Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized. While this API is not expected to be thread-safe, it
is not expected to crash. ztest on 64-thread system reproduced it
reliably for me.

Submitted by: avg@
MFC after: 1 month

show more ...

Revert "Fix race between first rand(3) calls."

It is going to be reimplemented with _once().

This reverts commit 28d70deaafa62c5d1602de5272c0aad0fcca8aff.

MFC after: 1 month

Fix race between first rand(3) calls.

Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized. While this AP

Fix race between first rand(3) calls.

Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized. While this API is not expected to be thread-safe, it
is not expected to crash. ztest on 64-thread system reproduced it
reliably for me.

MFC after: 1 month

show more ...

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

libc: Delete unused rand.c ifdef TEST code

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

General further adoption of SPDX licensing ID tags.

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

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier f

General further adoption of SPDX licensing ID tags.

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.

show more ...

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

2) Instead of doing range transformation in each and every function here,
do it single time directly in do_ran

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

2) Instead of doing range transformation in each and every function here,
do it single time directly in do_rand(). One "mod" operation overhead is not
a big deal, but the code looks nicer and possible future functions additions
or PRNG change do not miss range transformations neither have unneeded ones.

3) Use POSIX argument types for visible functions (cosmetic).

MFC after: 1 week

show more ...

libc: do not include <sys/types.h> where <sys/param.h> was already included

According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <

libc: do not include <sys/types.h> where <sys/param.h> was already included

According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <sys/types.h> when LOCORE is not defined).

show more ...

Use ANSI C prototypes. Eliminates -Wold-style-definition warnings.

Style fix noted by bde@

After fixing ranges restore POSIX requirement: rand() call without
srand() must be the same as srand(1); rand();
(yet one increment)

In addition to prev. commit, for repeated rand_r(3) calls don't forget
to compensate back at the end incremented at the start internal
state.

MFC after: 2 weeks

1) POSIX requires rand(3) return values to be in the [0, RAND_MAX] range,
but ACM formula we use have internal state (and return value) in the
[1, 0x7ffffffe] range, so our RAND_MAX (0x7fffffff) is n

1) POSIX requires rand(3) return values to be in the [0, RAND_MAX] range,
but ACM formula we use have internal state (and return value) in the
[1, 0x7ffffffe] range, so our RAND_MAX (0x7fffffff) is never reached
because it is off by one, zero is not reached too.

Correct both RAND_MAX and rand(3) return value, shifting last one
to the 0 by 1 subtracted, resulting POSIXed [0, 0x7ffffffd(=new RAND_MAX)]
range.

2) Add a checks for not overflowing on too big seeds. It may happens on
the machines, where sizeof(unsigned int) > 32 bits.

Reviewed by: bde [1]
MFC after: 2 weeks

show more ...

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.

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

Remove undefined behavior from sranddev() and
srandomdev(). This doesn't actually work
with any modern C compiler:

In particular, both clang and modern gcc
verisons silently elide any xor operation

Remove undefined behavior from sranddev() and
srandomdev(). This doesn't actually work
with any modern C compiler:

In particular, both clang and modern gcc
verisons silently elide any xor operation
with 'junk'.

Approved by: secteam
MFC after: 3 days

show more ...

libc: Use O_CLOEXEC for various internal file descriptors.

This fixes a race condition where another thread may fork() before CLOEXEC
is set, unintentionally passing the descriptor to the child proc

libc: Use O_CLOEXEC for various internal file descriptors.

This fixes a race condition where another thread may fork() before CLOEXEC
is set, unintentionally passing the descriptor to the child process.

This commit only adds O_CLOEXEC flags to open() or openat() calls where no
fcntl(fd, F_SETFD, FD_CLOEXEC) follows. The separate fcntl() call still
leaves a race window so it should be fixed later.

show more ...

Fix typo in the comment

Per Regents of the University of Calfornia letter, remove advertising
clause.

# If I've done so improperly on a file, please let me know.

Back out "drop first N values" method of removing monotonically increased
seed->first value correlation. It breaks rand_r()... Other possible methods
like shuffling inside aray will breaks rand_r() t

Back out "drop first N values" method of removing monotonically increased
seed->first value correlation. It breaks rand_r()... Other possible methods
like shuffling inside aray will breaks rand_r() too, because it assumes
only one word state, i.e. nothing extra can be added after seed assignment
in srand().

BTW, for old formulae seed->first value correlation is not so monotonically
increased as with other Linear Congruential Generators of this type only
becase arithmetic overflow happens. But overflow affects distribution
and lower bits very badly, as many articles says, such type of overflow
not improves PRNG.

So, monotonically increased seed->first value correlation problem remains...

show more ...

Since we drop NSHUFF values now, set default seed to what it becomes
after srand(1)

For rand(3) and random(3) TYPE_0 drop NSHUFF values right after srand{om}()
to remove part of seed -> 1st value correlation. Correlation still remains
because of algorithm limits. Note that old algor

For rand(3) and random(3) TYPE_0 drop NSHUFF values right after srand{om}()
to remove part of seed -> 1st value correlation. Correlation still remains
because of algorithm limits. Note that old algorithm have even stronger
correlation, especially in the lower bits area, but not eye-visible, as
current one.

show more ...