"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > This patch adds a 'random' module which implements: > > - random > - srandom > - initstate > - setstate > > and replaces: > > - rand > - srand > - RAND_MAX > > It depends on the 'random_r' module. > > random vs random_r > ------------------ > > It has to be said that while it is nice to have separate 'random' and > 'random_r' modules, their intimate dependence on the shared RAND_MAX > constant makes that hard to support. > > For example, if a platform has RAND_MAX defined to some value which > isn't 2147483647, and the Gnulib user pulls in 'random_r' but not > 'random', then they will see unexpected values returned from either > random() or random_r(). Either we override RAND_MAX with 2147483647, > or we leave RAND_MAX at the platform constant, but one way or the > other the platform random() or the Gnulib random_r() will return > values out of the expected range. > > So I think long term the only supportable solution is to fold > 'random_r' functionality into one big 'random' module that replaces > everything or nothing. > > On Windows, RAND_MAX is defined as 0x7fff, platform rand() returns > values in this range, and they have a reputation for not being very > random. (It appears Windows offers a separate CryptoAPI if you really > wanted random numbers).
Good point. However, what if an application wants only random_r? We shouldn't require that they import all of the non-thread-safe functions, too, so I think random really does belong separate. Of course, it depends on random_r no matter what. Perhaps then, random_r should not define RAND_MAX -- define a new symbol, e.g., RANDOM_R_MAX instead. Then only the random module would define RAND_MAX. > Locking > ------- > > As seems to be traditional with gnulib, I've removed the glibc > locking. cf. setenv and related modules. Strictly speaking this is a > violation of POSIX, since rand() is supposed to work even when called > in parallel from multiple threads. (It currently _won't_ work if you > try this - I expect you'll get strange corruption or even crashes). > I'm not sure if gnulib offers any sort of locking. People developing multithreaded applications on mingw will have bigger problems than this ;-) so defining away locks seems fine for now.
