Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: srand(0) Date: Thu, 08 Jan 2026 14:44:27 -0800 Organization: None to speak of Lines: 72 Message-ID: <87344fhghg.fsf@example.invalid> References: <10ib0ka$3cgil$1@dont-email.me> <10icocl$3u4ua$1@dont-email.me> <867bttph43.fsf@linuxsc.com> <87ikddgkc2.fsf@example.invalid> <10joipc$1jc43$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Thu, 08 Jan 2026 22:44:32 +0000 (UTC) Injection-Info: dont-email.me; posting-host="8f3ae4e77d372175ded3df1f10d77444"; logging-data="2009290"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX199ZCqr5zJR6NEC7mlQ97Lt" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:9kQdp2DZDeqA34tOcz0LxnwsoGU= sha1:yNV/2++MKMJM4nwv6e9k7XCFbVY= Xref: csiph.com comp.lang.c:396310 Michael Sanders writes: > On Wed, 07 Jan 2026 13:54:21 -0800, Keith Thompson wrote: >> Tim Rentsch writes: [...] >>> Apples and oranges. Many applications that use random numbers >>> need a stream of numbers that is deterministic and reproducible, >>> which /dev/urandom is not. >> >> And neither is the non-conforming rand() on OpenBSD. >> >> The rand(1) man page on OpenBSD 7.8 says: >> >> Standards insist that this interface return deterministic >> results. Unsafe usage is very common, so OpenBSD changed the >> subsystem to return non-deterministic results by default. >> >> To satisfy portable code, srand() may be called to initialize >> the subsystem. In OpenBSD the seed variable is ignored, >> and strong random number results will be provided from >> arc4random(3). In other systems, the seed variable primes a >> simplistic deterministic algorithm. >> >> It does provide an srand_deterministic() function that behaves the way >> srand() is supposed to. > > So then clang would use: > > #ifdef __OpenBSD__ > srand_deterministic(seed); > #else > srand(seed); > #endif > > But I don't know (yet) that gcc does as well under OpenBSD. I don't know what you mean when you say that clang "would use" that code. I'm not aware that either clang or gcc uses random numbers internally. I don't know why they would. You could certainly write the above code and compile it with either gcc or clang (or any other C compiler on OpenBSD). I've confirmed that gcc on OpenBSD does predefine the symbol __OpenBSD__. There should be no relevant difference between gcc and clang; random number generation is implemented in the library, not in the compiler. If your point is that a programmer using either gcc or clang could use the above code to get the required deterministic behavior for rand(), I agree. (Though it shouldn't be necessary; IMHO the OpenBSD folks made a very bad decision.) Relatedly, the NetBSD implementation of rand() is conforming, but of very low quality. The low-order bit alternates between 0 and 1 on successive rand() calls, the two low-order bits repeat with a cycle of 4, and so on. Larry Jones wrote about it here in 2010: The even/odd problem was caused at Berkeley by a well meaning but clueless individual who increased the range of the generator (which originally matched the sample implementation) by returning the *entire* internal state rather than just the high-order bits of it. BSD was very popular, so that defective generator got around a lot, unfortunately. And I've just discovered that the OpenBSD rand() returns alternating odd and even results after a call to srand_determinstic(). It's disturbing that this has never been fixed. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */