Re: [libvirt] [PATCH] random: don't mix RAND_MAX with random_r

On Thu, Aug 29, 2013 at 05:19:21PM -0600, Eric Blake wrote: > FreeBSD 10 recently changed their definition of RAND_MAX, to try > and cover the fact that their evenly distributed results really are > a smaller range than a full power of 2. As a result, I did some > investigation, and learned: >

> +/* The algorithm of virRandomBits relies on gnulib's guarantee that > + * random_r() matches the POSIX requirements on random() of being > + * evenly distributed among exactly [0, 2**31) (that is, we always get > + * exactly 31 bits). While this happens to be the value of RAND_MAX > + * on glibc, note that POSIX only requires RAND_MAX to be tied to the > + * weaker rand(), so there are platforms where RAND_MAX is smaller > + * than the range of random_r(). For the results to be evenly > + * distributed among up to 64 bits, we also rely on the period of > + * random_r() to be at least 2**64, which POSIX only guarantees for > + * random() if you use 256 bytes of state. */ > +enum { > + RANDOM_BITS_PER_ITER = 31, > + RANDOM_BITS_MASK = (1U << RANDOM_BITS_PER_ITER) - 1, > +}; Using an enum feels a bit wierd for this. Seems like these are simply 2 constants to #define.

ACK whether you change the enum or not.