Page MenuHomeFreeBSD

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

Authored by cem on Jan 21 2020, 2:07 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Dec 15, 3:26 PM
Unknown Object (File)
Mon, Dec 2, 9:59 AM
Unknown Object (File)
Mon, Nov 25, 7:24 AM
Unknown Object (File)
Sun, Nov 24, 8:27 PM
Unknown Object (File)
Sun, Nov 24, 10:38 AM
Unknown Object (File)
Sat, Nov 23, 10:07 PM
Unknown Object (File)
Nov 23 2024, 12:21 AM
Unknown Object (File)
Nov 22 2024, 4:51 PM
Subscribers

Details

Summary

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.

Relnotes: yes

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Jan 21 2020, 6:21 PM

Thanks for the quick reviews, Mark!

kevans added inline comments.
lib/libc/stdlib/rand.c
124 ↗(On Diff #67080)

I would maybe refrain from solidifying that the interface is "garbage" in a comment, but I don't really care more than to make this passing comment about it. =-)

lib/libc/stdlib/rand.c
124 ↗(On Diff #67080)

Call a spade a spade :P