src/lib/libc/stdlib/random.c, branch release/14.4.0FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=release%2F14.4.02023-11-27T04:20:09Zlibc: Purge unneeded cdefs.h2023-11-27T04:20:09ZWarner Loshimp@FreeBSD.org2023-11-01T22:43:37Zurn:sha1:4025b5b527c870cf095ac9531764f4e4d3feaec2
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)
Remove $FreeBSD$: one-line .c pattern2023-08-16T17:54:42ZWarner Loshimp@FreeBSD.org2023-08-16T17:54:42Zurn:sha1:1d386b48a555f61cb7325543adbbb5c3f3407a66
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
rand(3): Replace implementation with one backed by random(3) algorithm2020-02-01T20:33:23ZConrad Meyercem@FreeBSD.org2020-02-01T20:33:23Zurn:sha1:672e12255da9b211d5318889ed9441ffc63c9f30
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 state2020-01-24T01:39:29ZConrad Meyercem@FreeBSD.org2020-01-24T01:39:29Zurn:sha1:510b01833eaeb88ea926a878d5b44efc90f08301
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 object2020-01-24T01:32:16ZConrad Meyercem@FreeBSD.org2020-01-24T01:32:16Zurn:sha1:7382fafe454bef765efe97b01181af02b11c424f
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:47ZPedro F. Giffunipfg@FreeBSD.org2017-11-20T19:49:47Zurn:sha1:8a16b7a18f5d0b031f09832fd7752fba717e2a97
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 libc2016-10-12T13:56:14ZEd Masteemaste@FreeBSD.org2016-10-12T13:56:14Zurn:sha1:49a6e1ba328e7d0d9c3743c3d0a9306c7f188edd
Suggested by: jonathan (in review D8133)
abort in srandomdev if kern.arandom sysctl fails2016-10-05T17:03:22ZEd Masteemaste@FreeBSD.org2016-10-05T17:03:22Zurn:sha1:7e81ad1292587ce32b3a95291bc4e1fccd0de967
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:29ZEd Schoutened@FreeBSD.org2016-07-26T20:11:29Zurn:sha1:8de6c267117c2eb423b1a940601d8e4d525c5f4d
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 value2016-05-29T16:39:28ZAndrey A. Chernovache@FreeBSD.org2016-05-29T16:39:28Zurn:sha1:b8ac3f201ddfd20c820ae46f7a96a1b1812b02a4
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