You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several places in your code, you open /dev/urandom directly, and use that to feed into math/rand.Seed(). This breaks Windows tests, as /dev/urandom is Linux only.
Consider switching to crypto/rand.Read() as seed source instead, or just using current timestamp to seed with, that's universal.
Additionally in sortedset.go (init) you should not apply seeding. It's not really your library's responsibility to do so. For testing, modules, yes, but otherwise actually it's the programmers responsibility (perhaps they want to keep it unseeded for reproducable testing).
The text was updated successfully, but these errors were encountered:
Thanks for the bug report. I will try and put together a patch when I have a spare moment (but feel free to contribute one if you like). Some of this code (and the init's are part of it) comes from the pre-history of Go before there was a) windows support or b) rand.Read(). So that is likely why those init blocks are still around. I will check into whether ensure the randomization is necessary still. In the early days I don't think math/rand was seeded from a random source (it may be now).
Several places in your code, you open /dev/urandom directly, and use that to feed into math/rand.Seed(). This breaks Windows tests, as /dev/urandom is Linux only.
Consider switching to crypto/rand.Read() as seed source instead, or just using current timestamp to seed with, that's universal.
Additionally in sortedset.go (init) you should not apply seeding. It's not really your library's responsibility to do so. For testing, modules, yes, but otherwise actually it's the programmers responsibility (perhaps they want to keep it unseeded for reproducable testing).
The text was updated successfully, but these errors were encountered: