From: porkchop@invalid.foo   
      
   On Thu, 08 Jan 2026 14:44:27 -0800, Keith Thompson wrote:   
      
   > 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.   
      
   Well, I meant the macro itself is (I'm guessing) probably defined   
   by clang since its the default compiler.   
      
   > 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.   
      
   This is the info I'm, wondering about: both clang & gcc predefine   
   the symbol.   
      
   > 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.   
      
   Yikes! Thanks Keith. This is sort of odd for OpenBSD.   
      
      
   --   
   :wq   
   Mike Sanders   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)