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
This commit is contained in:
+5
-1
@@ -73,7 +73,11 @@ typedef struct {
|
||||
#define EXIT_FAILURE 1
|
||||
#define EXIT_SUCCESS 0
|
||||
|
||||
#define RAND_MAX 0x7ffffffd
|
||||
/*
|
||||
* I.e., INT_MAX; rand(3) returns a signed integer but must produce output in
|
||||
* the range [0, RAND_MAX], so half of the possible output range is unused.
|
||||
*/
|
||||
#define RAND_MAX 0x7fffffff
|
||||
|
||||
__BEGIN_DECLS
|
||||
#ifdef _XLOCALE_H_
|
||||
|
||||
Reference in New Issue
Block a user