random_r(3)

💖 random_r(3) — the reentrant random number generator girlies 💖

bestie. come sit. we're talking random_r(3) today, from the Library Functions Manual section 3, and honestly? it's giving "the popular one but with trust issues" because these are the thread-safe versions. obsessed.

✨ NAME ✨

random_r, srandom_r, initstate_r, setstate_r — the whole squad: reentrant random number generator functions. no cap.

---

🌈 LIBRARY 🌈

Standard C library (libc, -lc). yeah. the classic. 💅

---

🎀 SYNOPSIS 🎀

okay so first, the include, obviously:

#include <stdlib.h>

and here come the signatures, copy them EXACTLY, i'm not playing:

int random_r(struct random_data *restrict buf,
             int32_t *restrict result);
int srandom_r(unsigned int seed, struct random_data *buf);

int initstate_r(unsigned int seed,
             char statebuf[restrict .statelen], size_t statelen,
             struct random_data *restrict buf);
int setstate_r(char *restrict statebuf,
             struct random_data *restrict buf);

💜 Feature Test Macro Requirements for glibc (peep feature_test_macros(7) for the lore) 💜

random_r(), srandom_r(), initstate_r(), setstate_r():
    /* glibc >= 2.19: */ _DEFAULT_SOURCE
        || /* glibc <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE

so like. if you're on ancient glibc you gotta define _SVID_SOURCE or _BSD_SOURCE. _DEFAULT_SOURCE era girlies are chillin. 🦋

---

🌸 DESCRIPTION 🌸

so these functions are literally the reentrant equivalents of the ones described over in random(3). meaning? they're perfect for multithreaded programs where every single thread needs its own independent, reproducible sequence of random numbers. no fighting over global state, no drama, main character energy for each thread fr.

random_r() is giving random(3) but make it ✨selfish✨ — instead of using state info kept in a global variable, it uses the state info in the argument pointed to by buf, which must have been previously initialized by initstate_r(). the generated random number gets handed back to you in the argument result. 🎁

srandom_r() is like srandom(3), except it initializes the seed for the random number generator whose state lives in the object pointed to by buf — which, yes bestie, must have been previously initialized by initstate_r() — instead of the seed associated with the global state variable. she's independent. she doesn't share. 👑

initstate_r() is like initstate(3), except it initializes the state in the object pointed to by buf, rather than initializing the global state variable. ⚠️ before calling this function, the buf.state field must be initialized to NULL. also — and this is the important tea 🫖 — initstate_r() records a pointer to the statebuf argument inside the structure pointed to by buf. so like, statebuf should not be deallocated so long as buf is still in use. (which means: statebuf should typically be allocated as a static variable, or allocated on the heap using malloc(3) or similar.) don't free it early i'm begging 😭

setstate_r() is like setstate(3), except it modifies the state in the object pointed to by buf, rather than modifying the global state variable. state must first have been initialized using initstate_r() or be the result of a previous call of setstate_r(). periodt. 💅

---

⭐ RETURN VALUE ⭐

all of these functions return 0 on success. on error, -1 is returned, with errno set to indicate the error. yes ma'am, classic. 🌈

---

💀 ERRORS 💀

• EINVAL — a state array of less than 8 bytes was specified to initstate_r(). too small bestie, she needs at least 8 😭
• EINVAL — the statebuf or buf argument to setstate_r() was NULL. you cannot pass NULL, i will find you 🙈
• EINVAL — the buf or result argument to random_r() was NULL. same energy. stop it. 🍓

---

🔥 ATTRIBUTES 🔥

for an explanation of the terms used in this section, see attributes(7). here's the vibe check, table-ified into bullets because we're cute like that:

• Interface: random_r(), srandom_r(), initstate_r(), setstate_r()
• Attribute: Thread safety
• Value: MT-Safe race:buf

so they're MT-Safe but with a race on buf — meaning: don't go sharing one buf across threads without locking, iykyk. ✨

---

🧚 STANDARDS 🧚

GNU. yeah, she's a GNU girlie. that's the whole answer. 💜

---

🐛 BUGS 🐛

bestie, listen. the initstate_r() interface is confusing. it appears that the random_data type is intended to be opaque, but the implementation requires the user to either initialize the buf.state field to NULL or zero out the entire structure before the call. like. pick a lane. 💀 it's a documented bug note, not me being dramatic — that's literally what it says.

---

🫶 SEE ALSO 🫶

drand48(3), rand(3), random(3) — go read those too, bestie. knowledge is free and it's slay. 🌸

---

and that's the page!! 🎀 this was from Linux man-pages 6.20, dated 2026-02-08, random_r(3) — stan a thread-safe random generator, stay safe out there with your buf, and don't forget to init that state field to NULL or i'm gonna cry 😭💖 bye bestieeeee 🦋✨