[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] FreeBSD, no gcc present libvirt build issue

On 08/29/2013 09:43 AM, Eric Blake wrote:
> On 08/29/2013 09:35 AM, Jason Helfman wrote:
>>> stdlib.h:#define        RAND_MAX        0x7fffffff
> Good.
>>> -jgh
>> And on our current head release (10) it is this:
>> #define RAND_MAX        0x7ffffffd
> Huh?  Why is this not 2**n-1?  That violates assumptions we have made,
> and is WHY your compile failed.  It has nothing to do with clang vs. gcc
> (both compilers would fail), it has to do with your changed system
> header resulting in violating assumptions that hold in ALL OTHER
> IMPLEMENTATIONS, that random numbers are evenly distributed within a
> range of a power of 2.


makes it look like the reduction in range was _intentional_?  Yuck.  A
non-power-of-2 random generator adds needless complexity to the user.

I think I can fix libvirt to work around the boneheaded decision;
basically, since we cannot trust the full range of random_r to be evenly
distributed, I will have to tweak libvirt's call to truncate every call
to random_r to a subset of bits that are more likely to be evenly
distributed (maybe by shifting off the most- and least-significant bits
returned, and only using 28 instead of 31 bits of randomness per call).
 But I would MUCH rather prefer that FreeBSD revisit their decision, and
guarantee that random output be evenly distributed across the full 31
bits to begin with.

I also intend to open a bug against POSIX to request that RAND_MAX be
required to be 2**n-1, rather than relying on the assumption that
everyone so far, until FreeBSD 10, has happened to meet that requirement.

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

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]