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

1 files changed, 5 insertions, 1 deletions

diff --git a/include/stdlib.h b/include/stdlib.h
index 6adab32743d50..e84dca6ea42bb 100644
--- a/include/stdlib.h
+++ b/include/stdlib.h
@@ -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_