|
Revision tags: release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0 |
|
| #
b3e76948 |
| 16-Aug-2023 |
Warner Losh <[email protected]> |
Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0 |
|
| #
672e1225 |
| 01-Feb-2020 |
Conrad Meyer <[email protected]> |
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 ...
|
| #
510b0183 |
| 24-Jan-2020 |
Conrad Meyer <[email protected]> |
random(3): Abstract routines into _r versions on explicit state
The existing APIs simply pass the implicit global state to the _r variants.
No functional change.
Note that these routines are not e
random(3): Abstract routines into _r versions on explicit state
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
show more ...
|