2009/7/7 Antoine Latter <aslat...@gmail.com>: > If I were writing it as a library function, I would leave the function > as you described and let the caller make the choice. Calling into > randomIO in a library function is extremely dubious, as a second > library could be getting and setting the random seed used by randomIO > (see setStdGen). > > So I'm okay taking on that risk in an application I write, but I'm not > okay shipping that risk in a re-usable library, with the risk hidden > behind a type signature. > > Maybe I'm just paranoid.
You're not paranoid if they're really out to get you. I have been in a similar situation (on the other side: I discovered the flaw, and demonstrated an attack). I was in a Python class where our final project was a fairly fully-featured battleships game (3d graphics, network play and a computer player). Part of the evaluation (and a very fun part of the project) was an AI tournament. The TA gave us the code for the tournament server beforehand to that we could test our programs, and I observed that each player was loaded as a module into the same Python process. Python has both a global RNG and encapsulated RNG objects, but since it's an imperative language it's natural to use the global one and most people did. So one could seed the RNG at the start of each game to ones advantage: I tried this afterwards and beat all my opponents convincingly (in the real contest, where I didn't cheat, I was roughly equal to the two other top players and came second). > Antoine --Max _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
