1random_r(3)                Library Functions Manual                random_r(3)
2
3
4

NAME

6       random_r,  srandom_r, initstate_r, setstate_r - reentrant random number
7       generator
8

LIBRARY

10       Standard C library (libc, -lc)
11

SYNOPSIS

13       #include <stdlib.h>
14
15       int random_r(struct random_data *restrict buf,
16                    int32_t *restrict result);
17       int srandom_r(unsigned int seed, struct random_data *buf);
18
19       int initstate_r(unsigned int seed, char statebuf[restrict .statelen],
20                    size_t statelen, struct random_data *restrict buf);
21       int setstate_r(char *restrict statebuf,
22                    struct random_data *restrict buf);
23
24   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
25
26       random_r(), srandom_r(), initstate_r(), setstate_r():
27           /* glibc >= 2.19: */ _DEFAULT_SOURCE
28               || /* glibc <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE
29

DESCRIPTION

31       These functions are the reentrant  equivalents  of  the  functions  de‐
32       scribed  in random(3).  They are suitable for use in multithreaded pro‐
33       grams where each thread needs to obtain  an  independent,  reproducible
34       sequence of random numbers.
35
36       The random_r() function is like random(3), except that instead of using
37       state information maintained in a global variable, it  uses  the  state
38       information  in  the  argument  pointed to by buf, which must have been
39       previously initialized by initstate_r().  The generated  random  number
40       is returned in the argument result.
41
42       The srandom_r() function is like srandom(3), except that it initializes
43       the seed for the random number generator whose state is  maintained  in
44       the  object pointed to by buf, which must have been previously initial‐
45       ized by initstate_r(), instead of the seed associated with  the  global
46       state variable.
47
48       The initstate_r() function is like initstate(3) except that it initial‐
49       izes the state in the object pointed to by buf, rather than  initializ‐
50       ing  the  global  state  variable.   Before  calling this function, the
51       buf.state field must be initialized to NULL.  The  initstate_r()  func‐
52       tion  records  a  pointer to the statebuf argument inside the structure
53       pointed to by buf.  Thus, statebuf should not be deallocated so long as
54       buf  is still in use.  (So, statebuf should typically be allocated as a
55       static variable, or allocated on the heap using malloc(3) or similar.)
56
57       The setstate_r() function is like setstate(3) except that  it  modifies
58       the  state  in  the object pointed to by buf, rather than modifying the
59       global state variable.  state must first have  been  initialized  using
60       initstate_r() or be the result of a previous call of setstate_r().
61

RETURN VALUE

63       All  of these functions return 0 on success.  On error, -1 is returned,
64       with errno set to indicate the error.
65

ERRORS

67       EINVAL A state array of less  than  8  bytes  was  specified  to  init‐
68              state_r().
69
70       EINVAL The statebuf or buf argument to setstate_r() was NULL.
71
72       EINVAL The buf or result argument to random_r() was NULL.
73

ATTRIBUTES

75       For  an  explanation  of  the  terms  used  in  this  section,  see at‐
76       tributes(7).
77
78       ┌───────────────────────────────────┬───────────────┬──────────────────┐
79Interface                          Attribute     Value            
80       ├───────────────────────────────────┼───────────────┼──────────────────┤
81random_r(), srandom_r(),           │ Thread safety │ MT-Safe race:buf │
82initstate_r(), setstate_r()        │               │                  │
83       └───────────────────────────────────┴───────────────┴──────────────────┘
84

STANDARDS

86       GNU.
87

BUGS

89       The  initstate_r()  interface  is  confusing.  It appears that the ran‐
90       dom_data type is intended to be opaque, but the implementation requires
91       the  user  to either initialize the buf.state field to NULL or zero out
92       the entire structure before the call.
93

SEE ALSO

95       drand48(3), rand(3), random(3)
96
97
98
99Linux man-pages 6.04              2023-03-30                       random_r(3)
Impressum