random() always returns 0 with srandom(0)

2012-03-21 Thread Jeremy C. Reed
My co-worker was troubleshooting why some of our unittests (that work on 
multiple operating systems and architectures) failed on OpenBSD and saw 
that if you call srandom(0) to initialize the RNG, random() will always 
return 0.  (I was able to reproduce this.)

If this is expected behaviour, please point to explanation.

He posted his tests and discussed the code related to this at:

https://banu.com/blog/42/openbsd-bug-in-the-random-function/

He suggests two ways to fix this:

1) if (x == 0)
   x = 1;

upon entry in srandom(). That's the glibc way and he thinks is the 
better solution as it falls back to the default behavior (when srandom 
is not called) when the impossible seed=0 is passed.

2) the second way to fix it is the FreeBSD way:

   for (i = 1; i < rand_deg; i++) {
+if (state[i-1] == 0)
+  state[i-1] = 123459876;
   val = div(state[i-1], 127773);



Re: random() always returns 0 with srandom(0)

2012-03-21 Thread Stuart Henderson
On 2012/03/21 12:37, Jeremy C. Reed wrote:
> My co-worker was troubleshooting why some of our unittests (that work on 
> multiple operating systems and architectures) failed on OpenBSD and saw 
> that if you call srandom(0) to initialize the RNG, random() will always 
> return 0.  (I was able to reproduce this.)

Update src/lib/libc/random.c to r1.16.



Re: random() always returns 0 with srandom(0)

2012-03-21 Thread Theo de Raadt
> My co-worker was troubleshooting why some of our unittests (that work on 
> multiple operating systems and architectures) failed on OpenBSD and saw 
> that if you call srandom(0) to initialize the RNG, random() will always 
> return 0.  (I was able to reproduce this.)
> 
> If this is expected behaviour, please point to explanation.
> 
> He posted his tests and discussed the code related to this at:
> 
> https://banu.com/blog/42/openbsd-bug-in-the-random-function/
> 
> He suggests two ways to fix this:
> 
> 1) if (x == 0)
>x = 1;
> 
> upon entry in srandom(). That's the glibc way and he thinks is the 
> better solution as it falls back to the default behavior (when srandom 
> is not called) when the impossible seed=0 is passed.
> 
> 2) the second way to fix it is the FreeBSD way:
> 
>for (i = 1; i < rand_deg; i++) {
> +if (state[i-1] == 0)
> +  state[i-1] = 123459876;
>val = div(state[i-1], 127773);

Already fixed.

CVSROOT:/cvs
Module name:src
Changes by: mill...@cvs.openbsd.org 2012/03/21 06:36:49

Modified files:
lib/libc/stdlib: random.c 

Log message:
Fix a bug where random() always returns 0 when srandom() is seeded
with 0.  Use 1 and not 0 as the first element of the state array,
similar to what glibc does.  OK nicm@



Re: random() always returns 0 with srandom(0)

2012-03-21 Thread Stuart Henderson
On 2012/03/21 17:41, Stuart Henderson wrote:
> On 2012/03/21 12:37, Jeremy C. Reed wrote:
> > My co-worker was troubleshooting why some of our unittests (that work on 
> > multiple operating systems and architectures) failed on OpenBSD and saw 
> > that if you call srandom(0) to initialize the RNG, random() will always 
> > return 0.  (I was able to reproduce this.)
> 
> Update src/lib/libc/random.c to r1.16.
> 

er sorry, src/lib/libc/stdlib/random.c.



Re: random() always returns 0 with srandom(0)

2012-03-21 Thread Brad Smith

On 21/03/12 1:37 PM, Jeremy C. Reed wrote:

My co-worker was troubleshooting why some of our unittests (that work on
multiple operating systems and architectures) failed on OpenBSD and saw
that if you call srandom(0) to initialize the RNG, random() will always
return 0.  (I was able to reproduce this.)

If this is expected behaviour, please point to explanation.

He posted his tests and discussed the code related to this at:

https://banu.com/blog/42/openbsd-bug-in-the-random-function/

He suggests two ways to fix this:

1) if (x == 0)
x = 1;

upon entry in srandom(). That's the glibc way and he thinks is the
better solution as it falls back to the default behavior (when srandom
is not called) when the impossible seed=0 is passed.

2) the second way to fix it is the FreeBSD way:

for (i = 1; i<  rand_deg; i++) {
+if (state[i-1] == 0)
+  state[i-1] = 123459876;
val = div(state[i-1], 127773);


I assume you don't read the source-changes list.

CVSROOT:/cvs
Module name:src
Changes by: mill...@cvs.openbsd.org 2012/03/21 06:36:49

Modified files:
lib/libc/stdlib: random.c

Log message:
Fix a bug where random() always returns 0 when srandom() is seeded
with 0.  Use 1 and not 0 as the first element of the state array,
similar to what glibc does.  OK nicm@

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: random() always returns 0 with srandom(0)

2012-03-21 Thread Darrin Chandler
On Wed, Mar 21, 2012 at 12:37:47PM -0500, Jeremy C. Reed wrote:
> My co-worker was troubleshooting why some of our unittests (that work on 
> multiple operating systems and architectures) failed on OpenBSD and saw 
> that if you call srandom(0) to initialize the RNG, random() will always 
> return 0.  (I was able to reproduce this.)

Nice work by your co-working for pinpointing the problem, finding how
the issue was dealt with elsewhere, and proposing solutions, and then
making sure word got to an appropriate list. Please pass along my thanks
as an OpenBSD user.

-- 
http://code.phxbsd.com/



Re: random() always returns 0 with srandom(0)

2012-03-21 Thread Paul de Weerd
Hi Jeremy,

On Wed, Mar 21, 2012 at 12:37:47PM -0500, Jeremy C. Reed wrote:
| My co-worker was troubleshooting why some of our unittests (that work on 
| multiple operating systems and architectures) failed on OpenBSD and saw 
| that if you call srandom(0) to initialize the RNG, random() will always 
| return 0.  (I was able to reproduce this.)
| 
| If this is expected behaviour, please point to explanation.
| 
| He posted his tests and discussed the code related to this at:
| 
| https://banu.com/blog/42/openbsd-bug-in-the-random-function/

As already mentioned by others on this list, this was fixed in the
tree very recently, thanks to you and your co-worker for pointing it
out.

I'm curious though - how does a continuous stream of zeroes break your
unittests ?  I agree that it's pretty debianesque randomness (random()
is bad, but not *THAT* bad ;), but keep in mind that any RNG could in
theory produce an arbitrarily long sequence of zeroes too.

Can you provide some insight ?

Cheers,

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/