On 08/30/2013 03:36 AM, Daniel P. Berrange wrote:
> 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.

Using enums instead of #define makes gdb behave nicer - you can do 'p/x
RANDOM_BITS_MASK' and actually get a value, instead of having to dig up
the source file and look for the #define.

>
> ACK whether you change the enum or not.

Thanks; pushed after tweaking the comment to not trigger a false
negative during 'make syntax-check'.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org