While not exactly a bug, but if you run this code in Java:<p><pre><code> for(int i = 0; i< 100; i++){
Random random = new Random(i);
System.out.println(random.nextDouble());
}</code></pre>
It prints the following sequence (at least on JDK 7 and Win 7):<p><pre><code> 0.730967787376657
0.7308781907032909
0.7311469360199058
0.731057369148862
0.7306094602878371
0.730519863614471
0.7307886238322471
0.7306990420600421
0.7302511331990172
0.7301615514268123
</code></pre>
I know that you're not supposed to recreate the Random-instance like that but it's still a bit odd that the initial values in each sequence are so similar to each other.
Or why maybe using random() is a terrible idea. Use arc4random() instead on FreeBSD/OpenBSD/Mac OS X for a MUCH better random number generation, and best of all it is auto-seeded.<p>Obligatory XKCD: <a href="http://xkcd.com/221/" rel="nofollow">http://xkcd.com/221/</a>
One issue with the OpenBSD "bug" that i think hasnt been mentioned is that while openbsds srandom(0) leading to a 0 sequence sucks.
The fix everyone is using (including up to date OpenBSD trunk)
causes srandom(X) and srandom(Y) to produce the same sequence for at least one pair of distinct X and Y. This probably is less an issue but still. For example linux debian with gnu libc produces the same sequence after srandom(0) and srandom(1). Namely
1804289383
846930886
1681692777
1714636915
...